Issue 105418 - dynamic linkage of neon library
Summary: dynamic linkage of neon library
Status: CLOSED FIXED
Alias: None
Product: ucb
Classification: Code
Component: code (show other issues)
Version: OOo 1.0.0
Hardware: Unknown All
: P2 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: thorsten.martens
QA Contact: issues@ucb
URL:
Keywords:
Depends on:
Blocks: 99999
  Show dependency tree
 
Reported: 2009-09-28 11:50 UTC by Martin Hollmichel
Modified: 2012-09-10 21:19 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Martin Hollmichel 2009-09-28 11:50:40 UTC 
LGPL licensed neon library need dynamcic linkage.
Comment 1 tkr 2009-09-29 08:20:48 UTC 
accepted
Comment 2 tkr 2009-10-12 13:54:06 UTC 
fixed in tkr27
Comment 3 tkr 2009-10-15 07:35:34 UTC 
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.
Comment 4 tono 2009-10-18 04:53:06 UTC 
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.
Comment 5 thorsten.martens 2009-10-20 12:25:33 UTC 
checked and verified in cws tkr27 -> OK !
Comment 6 tkr 2009-10-22 09:12:50 UTC 
Reopen because of the Mingw build braker.
Comment 7 tono 2009-10-24 01:59:48 UTC 
@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.
Comment 8 tkr 2009-10-26 08:22:56 UTC 
@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
Comment 9 thorsten.martens 2009-11-03 12:52:51 UTC 
checked and verified in cws tkr27 -> OK !
Comment 10 andyrtr 2009-11-10 08:27:17 UTC 
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.