Apache OpenOffice (AOO) Bugzilla – Issue 50505
MacOS X: static libraries at the end
Last modified: 2013-02-07 21:49:19 UTC
Please provide better solution for $subject than transex3/source/makefile.mk contains in e.g. m109 where static library btstrp is put 6 times to the end and only for MacOS X.
See #i50458# for more details.
one way to handle this is to distinguish between shared and static libraries in each link makefile. (e.g. introduce SHLnSTATICSTDLIBS). as incorect assignments wouldn't show up imidiately, this may result in permanently fixing the assignments all over the code. another possibility is to atomatically move static libraries to the end of the library list when creating the link line. this in turn would require a mechanism to detect static libraries. here one may think of two ways: fetch the needed information from the filesystem or supply a manually maintained list of static libraries. both sulutions have their pros and cons... any comments?
ause: The crucial question is: For all compilers, does the order of libs matter (for now, forget about static libs at the end for broken MacOS X compiler)? If the answer is no, we can take care about this manually and just simply move the static libs at the end manually without inventing new mechanism. Do you know the answer?
@hr: you promised to comment :-)
hr->ause: You won't like the answer ... In general libs should be linked in descending order of dependencies that is libraries that depend on another library should be linked before that one. Static libs which contain "application code" which depends on other libraries should be linked before them (the linker just adds any objects from the static archive if it's needed to solve any missing symbol from the objects (including other static libs) which have been processed before. If the linker is advised to include the whole archive it's just the same as unarchving the objects with ar x libfoo.a and link them directly. The linking order is especially important if a symbol is provided by more than one shared library. Symbol resolution is done in a "directed graph" so it's well defined even if a symbol is provided twice, but the resolution will depend on the order of linking. Rememeber the story with libthread on Solaris? So answer is: In 98% of the cases (symbols are unique) the link order probably does not matter. But you can't depend on it for all cases.
i'm fine with it ;-) as i see this ------------------------------------- the linker just adds any objects from the static archive if it's needed to solve any missing symbol from the objects (including other static libs) which have been processed before ------------------------------------- as the core statement, it can't make things worse to automatically move static libraries at the end of the link line without changing the order between them. that's the information needed to think about some magic ;-)
is this issue still valid ?