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.
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:
> 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
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?
> 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
> 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.
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