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 14:29:39

On Sunday 17 September 2006 22:15, John Maddock wrote:
> Vladimir Prus wrote:

John,
can you CC the list on reply, or reply just to the list. I've replied both to 
you and the list to make sure you don't miss the email, but now it's no 
longer needed ;-)

> >> 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...
>
> Oh, I see.
>
> However the executable isn't inheriting <threading>multi so I wouldn't
> expect it's dependents to do so.  

Both inherit <threading>multi, but executable has explicit <threading>single, 
which overrides inherited value.

> Even if the the auto-linking wasn't 
> triggering an error, the lib wouldn't be binary compatible with the exe :-(
>
> It would help enormously - and cut down on support requests to you I
> suspect - if there was some kind of indication (warning or error) when
> conflicting requirements are set.

The problem with any error or warning is that there are situations where it's 
not appropriate, and I don't know any mechanism to specify "I mean it". 
Maybe, we can have new command line option --debug-incompatible, that would 
print all possible problems?

> >> 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.
>
> Ah, looks like we've been stung by history here:
>
> msvc-6.0  : vc6
> msvc-7.0 : vc7
> msvc-7.1 : vc71
> msvc8.0 : vc80
>
> I could change the auto-link code to add the "0" to the older toolsets, but
> we'd probably have to change bbv1 and make sure it works as well :-(

I think it's easier to adjust V2 to use the above naming scheme. Should be 
easy.

> >> 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.
>
> Yep, I realise that now.  Problem is it's a *very* easy trap to fall into.
> The fewer support requests we get from newbe's building Boost the better.
>
> >> 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?
>
> Or when --help is used?  The problem with --debug-configuration is it's not
> easily "discoverable" by a casual user who just wants to get things
> installed.

Not sure. Anyway, --help should mention --debug-configuration
Filed an issue:
   https://zigzag.cs.msu.su:7813/boost.build/ticket/104

> >>> 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 think static library + dynamic runtime is fine everywhere, it's the
> reverse: static runtime + dynamic library that leads to two copies of the
> runtime and all kinds of problems (at least on windows).

On Linux, static runtime + dynamic library is just not possible. This suggests 
we should not ever try to build that combination, since it does not make 
sense for any platform.

On the other hand, I recall Dave told that static runtime + dynamic library 
can actually be made to work, if one is carefull. 

> >> 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.
>
> Not with msvc: single and mt variants use different runtimes.  It's not
> true for all compilers and platforms though as you say.

Filed issue:
    https://zigzag.cs.msu.su:7813/boost.build/ticket/105

Feel free to add suggestions to it.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2