Re: [boost] Re: Re: Re: more config/auto_link nitpicks

From: John Maddock (john_at_[hidden])
Date: 2003-11-08 07:57:52

> >Rene - is there any way in which a test that is dependent upon say
> ><lib>whatever could actually be made dependent upon the staged and
> >name-mangled version of that library ?
>
> Not currently, and adding it would be difficult.
>
> Changing things so that you can depend on the name manged versions
directly
> (not going through the stage targets) is less difficult. Let me think
about
> it and get back to you.

OK I've done some experimenting and I think that we are almost there, but
first let me describe the issue better:

When a library and the compiler-toolset building it supports auto-linking,
then the mangled name of the library to link to gets embedded in the object
file, and the result is a linker error unless the library specified is found
in the linkers search path.

Now this feature can be turned off by defining a macro when building - but
that's intrusive - particularly for something like the unit test lib where
both that lib's test programs, and all programs using it have to add the
define to their build requirements in their Jamfiles.

In other words a feature that's great for end users, messes up the bjam
based test suites.

First the good news: I added [ common-names ] to the requirements for the
boost_regex dll and lib rules, and voila! all the test programs
automagically become dependent upon the name-mangled library versions.

Then I disabled the <define>BOOST_REGEX_NO_LIB=1 that I was using to
suppress auto-linking, and those targets dependent upon the regex dll built
OK, because for some reason the path containing the dll (and it's lib) was
added to the linkers library search path.  However targets dependent upon
the regex lib failed because this lib file was not in the linker search
path - checking the command lines showed that there is a real difference
between targets dependent upon dll's and lib's here.

So... I looked in boost-base.jam but couldn't figure out where the extra
<library-path> option was coming from for targets dependent on dll's, but
can we add something similar for libs, so that any target dependent upon a
lib gets the directory containing it added to the linkers library-path.  I
think that will pretty much solve everything (as far as I can tell if the
same lib is found by two different mechanisms - auto-linking and explicitly
being listed on the command line - then that's OK, it's only an issue if
these two mechanisms don't refer to the same lib file).

Now one final, maybe not so important issue: if the user builds with the
"wrong" toolset - lets say msvc when they are using vc7.1 - then the lib's
will get the wrong mangled name, because the name mangling scheme is
dependent upon the toolset name, not the "real" compiler version.  That
means that the library name as seen by bjam,and that inserted into object
files by the auto-link mechanism will be different.  Would it be possible to
invoke the compiler to get the "real" toolset version name - this is only
really an issue for msvc and borland (which have auto-linking enabled), and
maybe gcc (which doesn't, but there is only one gcc toolset so there is no
difference in lib names if you build with gcc2.95 or gcc3.3 - don't know how
much that matters though).

Whew, almost there,

Thanks!

John.