Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | dynamic linkage of neon library | ||
---|---|---|---|
Product: | ucb | Reporter: | Martin Hollmichel <nesshof> |
Component: | code | Assignee: | thorsten.martens |
Status: | CLOSED FIXED | QA Contact: | issues@ucb <issues> |
Severity: | Trivial | ||
Priority: | P2 | CC: | andreas.radke, issues, pfg |
Version: | OOo 1.0.0 | ||
Target Milestone: | OOo 3.2 | ||
Hardware: | Unknown | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Issue Depends on: | |||
Issue Blocks: | 99999 |
Description
Martin Hollmichel
2009-09-28 11:50:40 UTC
accepted fixed in tkr27 TKR->TM: Please verify on all platforms. In the basis layer of the office installation you will find a new library (Windows: neon.dll / Linux/Unix: libneon.so / macos: libneon.dylib). To verify this issue try to open a document via webdav on each platform. The import library on Windows platform is being renamed from ineon.lib to neon.lib at delivery time. Is it essential to do so or can we modify solenv/inc/libs.mk instead of renaming the library? Conventionally the name of the import libraries are different from the shared target names. I do not know the reason why but it made mingw port simple. Mingw port really does not use the .lib style import libraries and create empty dummy files just for clearing the dependencies. And if the core name of the import libraries are different from the shared target, the linker can safely use dll-direct-linking without troubles. If the core name of the import librbarary is the same as the dll, the empty dummy file will be used for linking and will cause problem. Currently the cws tkr27 is broken on MinGW but it will be safely buildable if we stop renaming ineon.lib at delivery time and set NEON3RDLIB to ineon.lib for Windows MSVC build in solenv/inc/libs.mk. checked and verified in cws tkr27 -> OK ! Reopen because of the Mingw build braker. @tkr: Since mingw port does not use import library but use direct-dll-linking instead, NEON3RDLIB should not be changed to -lineon from -lneon. The file ineon.lib will be used only in normal MSVC build. @tono: Changes commited. Please take a look on it. Since our internal mingw built-bot doesn't work properly maybe you can do me a favor and check the mingw port to verify that the build issue was solved. -> Fixed checked and verified in cws tkr27 -> OK ! m4 is brokwith system neon for me. ERROR: ERROR: Missing files in function: remove_Files_Without_Sourcedirectory ************************************************** ************************************************** ERROR: Saved logfile: /tmp/openoffice-base-beta/trunk/src/OOO320_m4/instsetoo_native/unxlngx6.pro/OpenOffice/native/logging/en-US/log_OOO320_en-US.log ************************************************** ... reading include pathes ... ... analyzing script: /tmp/openoffice-base-beta/trunk/src/OOO320_m4/solver/320/unxlngx6.pro/bin/setup_osl.ins ... ... analyzing directories ... ... analyzing files ... ... analyzing scpactions ... ... analyzing shortcuts ... ... analyzing unix links ... ... analyzing profile ... ... analyzing profileitems ... ... analyzing modules ... ------------------------------------ ... languages en-US ... ... analyzing files ... ERROR: The following files could not be found: ERROR: File not found: libneon.so ... cleaning the output tree ... ... removing directory /tmp/ooopackaging/i_32551257776001 ... Mon Nov 9 14:13:24 2009 (00:03 min.) dmake: Error code 255, while making 'openoffice_en-US.native' We should reopen this one. |