Re: [boost] Re: Boost Test Library and Boost.Build

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-10 19:44:05

From: "Gennadiy Rozental" <rogeeff_at_[hidden]>

> > > c.  Directory tree created by jam does not include OS we are building
> on.
> > > What will happened if I will start compiling in the same directory
using
> > let
> > > say gcc from NT box and some UNIX box?
> >
> > You'll be screwed. That's why you should use ALL_LOCATE_TARGET to set
up a
> > separate build tree for each platform.
>
> I was trying to use ALL_LOCATE_TARGET. I use it for building in the
> directory boost/libs/test/build. I defined it as ./DEBUG. To my surprise
it
> created directory boost/Debug as a sparate build tree.

That surprises me also. However, using a relative path for
ALL_LOCATE_TARGET sort of defeats the purpose.

> > > 2. Sunpro
> > > While working on sunpro compilation I found 2 strange things:
> > >
> > > a. I have libraries Jamfile in build directory and test Jamfile in
test
> > > directory. test are dependent on libraries. Let say test T is
dependant
> > on
> > > library L and it is failing. I am changing some headers used in both
T
> > and
> > > L. I am starting T compilation. First jam decides to rebuild some of
the
> > L
> > > sources that depend on headers changed. It did. But then it failing
> > linking
> > > the library cause object files for sources that were not rebuild are
> > > missing.  jam happily ignore this failure and continue with T
> > compilation.
> >
> > What's so strange about that? Jam does all the work it can. It can't
link
> > T, because the library is missing, but it can try to compile T.
>
> No. You did not get it. Here the order of actions:
>
> 1. I successfully compiled library L from L_source1.cpp and L_source2.cpp
> 2. I compiling test T from T_source.cpp and it's failing
> 3. I change header that is included both in T_source.cpp and
L_source1.cpp.
> 4. I restarting T compilation.
> 5. Jam first found that it need to recompile L_source1.cpp.
> 6. Next It tries to relink library L. And it *fails*, cause L_source2.o
is
> missing.

It actually tries to invoke the linker even though L_source2.o is missing?
Or does it report <skipping ... due to missing L_source2.o>?
That's what's supposed to happen.

> 7. Jam happily ignore it and continue with compilation of T_source.cpp
> 8. Jam link T_source.o with wrong version of library L.

Hmm, that doesn't happen for me. Can you zip up and post a tiny Jam project
which reproduces this problem?

> In my case it worked and linked cause of the nature of changes I made.
But
> in general it could dangerous.

I've never seen this behavior before. Are you sure you're not
misinterpreting the results? For example, you might be seeing a successful
link of the release variant while the debug build failed.

> > Jam continues with whatever work it can do. I don't think it will stage
> any
> > targets which fail to build, unless there's a bug in the stage rule.
> >
>
> I rechecked. run rule continue with link even if compilation fails.

That's really strange.

> > > 3. GCC
> > > After minor changes  I made gcc 3.0 compile the libraries. But when I
> > > started to compile tests gcc produces a myriads of "template with C
> > linkage"
> > > errors. Look on gcc.out attached. Any help is greatly appreciated.
> >
> > You probably have an extern "C" { ... } around your template
declaration.
> > Try preprocessing the source to see what's going on.
>
> I don't think so. It from gcc STL implementation. Look onto gcc.out. Here
an
> example:
>
>
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-
3
> /stl_alloc.h:142: template with C linkage

If a boost header got included before an std header it could easily have
left a dangling extern "C" { around.

Check the preprocessor output, really.

Also, did you install GCC on this system without using --prefix= to keep it
out of the way of other GCC installations? That's a common cause of library
problems.

-Dave