Re: [jamboost] Boost.Build Feature request

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-21 08:25:57

Hi Tomas,

> > I don't insist, it's just better to know all the use cases we
> > have to support.
>
> Say we have library A that links with a library B.
> Then I use functionality from libB in my application, so I add it to the
> link line, too.
> Everything is fine.
>
> Then at some later time I decide that I wish to debug the application
> and also need libB debug. Such a lib would be called libB-g. So I
> rebuild the app in debug mode and then relink it, pulling in libA,
> libB-g, and I think you can now see that this will cause problems.
>
> The way we avoid these problems is by keeping the dependency tree only 1
> level deep, i.e. only the executable has library dependencies.

Ok, understood. I can mention another approach. Create to directories, "debug" 
and "release". Add them, in that order, to LD_LIBRARY_PATH. When you build 
release libraries you put them to the "release" directory. When you want to 
debug libB you build it, *with the same* name and put the resulting library 
to "debug". Now, everything start to use that debug version of libB. This 
might not be a solution for you though.

> > > > What are "additional libraries"?
>
> The support libs are:
> RW STL V6.0
> libsupc++.a
>
> Now I know what you are going to say - you will say that libsupc++.a is
> an archive, so hence my problems, but the linker errors were for our STL
> symbols, hence my (wrong) conclusion.

Ok, now we're on the same page.

> Anyway, instead of trying to explain all of my mistakes, maybe you could
> help me to get boost building the way we need in our environment?

I was just trying to diagnose the problem.

> Please see the Makefile below with my comments:
........
> #Now this is the tough one
> #Build (and run) regression tests in the build area against the freshly
> build '.so's
> #from the install area, just to check everything has been built
> correctly

I'm not sure this is possible. The boost test are written in such a way as 
using the buillt libraries, not the installed ones. 

> #Note that you must:
> #1) use "gcc" and not "g++" as the compiler (long story)

I think -sGXX=gcc parameter to bjam will do this

> #2) add libstd.so
> #3) add libsupc++.a as the last thing on the link line.
> run_tests:
> ?

I've tried running:

bjam -sGXX=gcc -n -sBUILD="<find-library>std <find-library>supc++" in the

libs/format/test directory and the output is:

"gcc" -g -o 
"../../../bin/boost/libs/format/test/format_test1.test/gcc/debug/format_test1" 
-L"../../../bin/boost/libs/test/build/libboost_test_exec_monitor.a/gcc/debug" 
"../../../bin/boost/libs/format/test/format_test1.test/gcc/debug/format_test1.o" 
"../../../bin/boost/libs/test/build/libboost_test_exec_monitor.a/gcc/debug/libboost_test_exec_monitor.a" 
"../../../bin/boost/libs/test/build/libboost_test_exec_monitor.a/gcc/debug/libboost_test_exec_monitor.a" 
-lstd -lsupc++ -Wl,-rpath-link,.

Does that seem OK?

- Volodya