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

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2003-11-08 13:46:21

[2003-11-08] John Maddock wrote:

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

[snip] ... Got that :-)

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

Yes there is a difference, for dlls not only does the path get added to the
command line, but it also gets set to the environment, LD_LIBRARY_PATH on
Unix.

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

Yes, and done... here's the diff so you see where it is..

Index: boost-base.jam
===================================================================
RCS file: /cvsroot/boost/boost/tools/build/v1/boost-base.jam,v
retrieving revision 1.110
retrieving revision 1.111
diff -u -d -r1.110 -r1.111
--- boost-base.jam  7 Nov 2003 05:29:13 -0000   1.110
+++ boost-base.jam  8 Nov 2003 18:32:51 -0000   1.111
@@ -1655,6 +1655,7 @@
 {
     NEEDLIBS = [ unique $(NEEDLIBS) $(>) ] ;
     NEEDLIBS on $(<) = [ on $(<) return [ unique $(NEEDLIBS) $(>) ] ] ;
+    LIBPATH on $(<) += [ unique $(gLOCATE($(>))) ] ;
     DEPENDS $(<) : $(>) ;
     # To run these targets, we need everything needed to run the libraries
     gRUN_PATH($(<)) = [ unique $(gRUN_PATH($(<))) $(gRUN_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).

And given that the paths are target specific, with the .a .lib etc in them,
it's unlikely it will end up with two pointing to the same lib.

>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).

O' thee holly grail ;-)

Can't do it right now... None of us have had the time to implement a SYSTEM
builtin to bjam :-( It's a fair amount of work. But if someone would like to
contribute a tested cross-platform system/exec code that captures output it
would speed things up ;-)

-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq