Re: [Boost-build] <link>static not working and/or properties not propagated up to dependencies?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-09-17 13:32:26

On Sunday 17 September 2006 20:08, John Maddock wrote:

> > Is ".." in "..//link_test/<link>static" a typo? Did you mean "."? The
> > problem is that you have "link_test" target in
> > libs/config/test/link/test/Jamfile.v2 and in Jamfile.v2 one directory
> > up. Your libs/config/test/link/test/Jamfile.v2 references link_test
> > from upper-level Jamfile.v2, and the definition there is:
> >
> >   lib link_test : link_test.cpp
> >
> >      : <link>shared <runtime-link>shared
> >
> >        .....
> >
> > This <link>shared is "final overrider" -- it overrides everything
> > specified everywhere else. I suspect you really wanted to just use
> > "link_test", without "..".
>
> Doh! yes!
>
> However, if I change the reference to ".//link_test" I see the same issue,
> but with simply "link_test" it does work.
>
> OK, with VC8 everything works as expected, and all the names match up OK.
> Good.

I'm surprised it works, see below.

>
> There are a few problem still though:
>
> 1) With VC-7.1 I see two failures summarised by:

> And the response file for the linker contains:
>
> "..\..\..\..\..\bin.v2\libs\config\test\link\test\link_test_static_single_d
>ebug.test\msvc-7.1\debug\link-static\runtime-link-static\main.obj"
> "..\..\..\..\..\bin.v2\libs\config\test\link\test\msvc-7.1\debug\link-stati
>c\runtime-link-static\threading-multi\liblink_test-vc71-mt-sgd-1_35.lib"
>
> So it's trying to link to the <threading>multi lib file, even though the
> executable is <threading>single.

With CVS HEAD (or RC branch) as of one minute ago, you add --debug-building 
option to bjam and will find that the 'link_test' has '<threading>multi' in 
requirements. That's not explicitly set, but it's inherited from 
libs/config/test/Jamfile.v2 (which in turns gets that from options_v2.jam).

Unfortunately, there's no easy way to 'cancel' parent requirements. Let me try 
to implement one...	

> (In case you're wondering why this is an issue, it's because these two
> variants use different runtime libraries).
>
> 2) With VC-7 nothing links:
>
> If my toolset is configured with:
>
> using msvc : 7 : path... ;
>
> Then the lib files are mangled with "vc" and no version number.
>
> If I configure with:
>
> using msvc : 7.0 : path... ;
>
> The the lib files are mangled with "vc70" but the auto-linking code expects
> "vc7" which is the name we have used historically.
>
> 3) I haven't been able to test with VC6, if my config contains
>
> using msvc : 6 : path ;
>
> then I get "vc" as the manged name rather than "vc6".
>
> Presumably there is a "fuller" version number I could use, to get a mangled
> name, but I don't know what it is.  Is it documented anywhere?

I think you're expected to always provide N.N version. Speaking about vc70 vs 
vc7 -- I can fix that in a moment, as soon as you tell me if for 8.0 we 
should be using vc8 or vc80.

> 4) Similarly if my user-config.jam contains:
>
> using msvc : 8 : path ;
>
> I don't get correctly named lib files, they're just mangled with "vc" not
> "vc8".

Again, use '8.0' as version.

>
> 5) If I use:
>
> using msvc : all ;
>
> How do I find out what the compiler variants are called?

I don't know, unfortunately. Probably we need print detected versions 
when --debug-configuration is specified?

> "msvc-6" 
> certainly isn't recognised as a valid toolset name.

Again, I suspect msvc-6.0 will work.

> > Do you mean that:
> >
> >   - <runtime-link>static should automatically switch <link>static
> >   - attempt to use <runtime-link>static together with <link>shared
> >     should result in error or warning.
>
> Either: the point is it's an "impossible" combination, at least on this
> compiler, and maybe everywhere?

Not everywhere, on Linux, static library linking to dynamic runtime is fine. 
In fact, static runtime is kind of deprecated.

> I guess it would be nice if:
>
> 1) <runtime-link>static made <link>static the default.

That's a bit hard -- we don't support such implicit interactions between 
features.

> 2) Conflicting requirements caused an error: so for example if an exe has
> <threading>multi and a lib it depends on <threading>single then we should
> see an error, as there's no way we can satisfy both sets of requirements.
> I'm fairly sure bbv1 used to do this, albeit in a limited way.

We used to have this in V2 ("link compatibility"), but then I decided we can't 
implement this in a sufficiently usefull way. For example, I though I can 
link mt library into single-threaded executable. 

- Volodya