Issue 50505 - MacOS X: static libraries at the end
MacOS X: static libraries at the end
Status: CONFIRMED
Product: porting
Classification: Code
Component: MacOSX
current
All Mac OSX, all
: P4 trivial (vote)
: DevTools
Assigned To: AOO issues mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-08 21:18 UTC by pavel
Modified: 2013-02-07 21:49 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description pavel 2005-06-08 21:18:48 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.
Comment 1 pavel 2005-06-08 21:19:15 UTC
See #i50458# for more details.
Comment 2 hjs 2005-06-17 12:08:04 UTC
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?
Comment 3 pavel 2005-06-17 17:57:43 UTC
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?
Comment 4 hjs 2005-08-16 17:10:33 UTC
@hr: you promised to comment :-)
Comment 5 jens-heiner.rechtien 2005-08-17 12:17:36 UTC
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.
Comment 6 hjs 2005-08-17 12:37:49 UTC
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 ;-)
Comment 7 Martin Hollmichel 2010-07-26 19:54:09 UTC
is this issue still valid ?