Re: [Boost-build] EXE linking with DLLs

Subject: Re: [Boost-build] EXE linking with DLLs
From: Nogradi, Chris (Chris.Nogradi_at_[hidden])
Date: 2012-07-09 22:45:16

> On 01/12/11 01:24, Nogradi, Chris wrote:

> > What I ended up doing is to modify targets.jam line 1421 like so:
> >
> >          # TODO - Actually there are more possible candidates like for instance
> >          # when listing static library X as a source for another static library.
> >          # Then static library X will be added as a<source>  property to the
> >          # second library's usage requirements but those requirements should last
> >          # only up to the first executable or shared library that actually links
> >          # to it.
> >          local raw = [ $(subvariant).sources-usage-requirements ] ;
> >          raw = [ $(raw).raw ] ;
> >          raw = [ property.change $(raw) :<pch-header>  ] ;
> >          raw = [ property.change $(raw) :<pch-file>  ] ;
> >
> >            # remove libraries from shared link targets
> >              if <link>shared in [ $(rproperties).raw ]
> >          {
> >              raw = [ property.change $(raw) : <library> ] ;
> >          }
> >          return [ $(result).add [ property-set.create $(raw) ] ] ;

> Friday, December 02, 2011 7:06 AM Vladimir Prus wrote:
>
> Can you remind what is the problem with linking additional static
> libraries to the application? Is this performance, or you get link
> errors as the result?
>

> On Monday, December 05, 2011 8:42 AM Chris Nogradi wrote:

> Volodya,
>
> Thanks for looking at this issue.
>
> The example in builtin.jam looks reasonable to me as I would not want
> system libs installed supposing they already are.
>
> The reason we do not want the extra static libraries linking to the exe
> is that the symbols needed by the exe are exported by dlls and are also
> available in the static libs that were used to build the dlls.  So
> depending on the order of the linking, we could link against the
> symbols in the static libs instead of the dlls. And so yes we do get
> link errors because the linker pulls in the wrong version of the
> symbols and then requires additional symbols that are not available in
> the libraries because it should have used the dll exported symbols.
>
> lib A : file1.c : <link>static ;
> lib B : file2.c : <link>static ;              # symbols in this lib are
> also exported by dll-B
> lib C : file3.c A B : <link>static ;
> lib D : file4.c B : <link>static ;
> lib dll-A : file5.c C : <link>shared ;
> lib dll-B : file6.c D : <link>shared ;
>
> exe test : main.c dll-A dll-B ;
>
> the command line order to the linker looks something like this:
>
> main.obj
> libdll-A.lib
> libA.lib
> libB.lib
> libdll-B.lib
>
> So the linker pulls in the symbols from libB.lib rather than the
> exported symbols from libdll-B.lib that should have been used.
>
> It is interesting that C and D are properly handled as they are not
> added to the final exe link but A and B remain as part of <library>
> properties. I don't think this is the right behavior since the library
> dependencies should cease at the first shared library or exe.  If for
> some reason it is desired that a library dependency remain beyond a
> shared library or exe, usage-requirements should be specified for the
> shared lib or exe.
>
> Hope this helps.
>
> Chris

Does anyone have any thoughts on making this or a similar compatible change so that I can dump my local branched version.

Thanks,

Chris

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.

Thank you for your cooperation.