Re: [Boost-build] EXE linking with DLLs

Subject: Re: [Boost-build] EXE linking with DLLs
From: Nogradi, Chris (Chris.Nogradi_at_[hidden])
Date: 2011-12-05 09:42:03

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

-----Original Message-----
From: boost-build-bounces_at_[hidden] [mailto:boost-build-bounces_at_[hidden]] On Behalf Of Vladimir Prus
Sent: Friday, December 02, 2011 7:06 AM
To: boost-build_at_[hidden]
Subject: Re: [Boost-build] EXE linking with DLLs

On 01/12/11 01:24, Nogradi, Chris wrote:
> Thanks Matt!
>
> I did not have opportunity to try your suggestion out yet since it would require me to re-architect many jam files.  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 [ $(rproperties).get<link>  ] = shared
>          {
>              raw = [ property.change $(raw) :<library>  ] ;
>          }
>          return [ $(result).add [ property-set.create $(raw) ] ] ;
>
> which seems to do what I want but is probably not the right solution for all.
> I suppose it would be better to remove<library>  for exe and shared link targets but I did not know how to do that. Maybe someone is willing to educate me?

Hi Chris,

the code that adds <library> in the first place is inside builtin.jam, around line 919. There's also
comment explaining why it works this way. To be honest, I am not longer sure why example in the
comment makes sense :-(

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?

Thanks,
Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

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.