Subject: Re: [Boost-build] Linker library ordering
From: Nogradi, Chris (Chris.Nogradi_at_[hidden])
Date: 2016-07-26 17:33:02
> On Tuesday, July 12, 2016 1:08 PM, Vladimir Prus wrote:
> Hi Chris,
> the reason we're doing this is that Unix linker is sensitive to the order of
> static libraries. If you have
> g++ -o binary main.o -la -lb
> then only symbols in a that are known to be needed are included. So, if
> library b depends on a, those symbols won't be resolved, because at the time
> the linker processes -la, it haven't yet processed -lb and therefore does not
> know about any needed symbols.
> it seems that this is now the case for shared libraries as well.
> Now, there's an option to GNU linker that say "please do for static libraries
> what MSVC does" - which is to iterate symbol resolution process until it
> stabilizes. However, it does not appear to work for shared libraries.
Thanks Volodya for the quick response. I think I understand what is going on now. If the linker is set to gnu then the gcc module always uses the gcc linker --start-group/--end-group command line options which would cause the behavior to be just like msvc. So I am thinking that if this is the selected link type, then the sorting should not be done. I'll have to investigate if this works for shared libraries and if not adapt the implementation appropriately (in our case we are developing for raw hardware so we only use static libs).
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk