Re: [jamboost] Re: V2 testing

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

Hi Vincent,

> > Can you tell me the name of "bin...." directory created in "jam_src" when
> > you was building bjam, so that I can fix this?
>
> I guess it's under boost/tools/build/jam_src/bin.aix/

Ok.

> > > Don't know directory where jam is build for this system: posix/IRIX64
> >
> > Same question here. The Boost.Build test system expects that you've build
> > bjam in jam_src and tries to find the "bin" directory there. But for the
> > systems above, it does not know the right path.
>
> boost/tools/build/jam_src/bin.irix

Thanks.

> > > > > -AthlonMP1900+(x86-32) GNU/Linux 2.4.18-smp (RedHat 8.0)/icc 8.0
> > > >
> > > > The test result indicate that gcc is being used, not icc.
> > >
> > > I guess the test_all script doesn't read my user-config.jam and as
> > > cc=gcc is default on RH8, I now changed the .bashrc of qa user to use
> > > alias cc=icc before running test_all. Hope this will force icc to be
> > > used on this RT at the next run.
> >
> > Ok,
> >
> > > > > -Athlon(x86-32) GNU/Linux 2.4.21 (SuSE 9.0)/gcc 3.3.1
> > > >
> > > > Some of the test failures say that you did not configure "icc"
> > > > correctly on that box. Anyway, it's not a big problem.
> > >
> > > Yes, I saw it this morning. I had both gcc & intel-linux in my
> > > user-config.jam but I commented-out intel-linux as I removed the intel
> > > compilo from my host, it seems that the # is innefective so I removed
> > > the whole line "using intel-linux" below "using gcc". Let's see at the
> > > next run.
> >
> > Ok. Do you have "test-config.jam" in the "test" directory. Is you have
> > this file, it overrides "user-config.jam" which can explain why editing
> > user-config did not have any effect.
>
> I don't have this file under my ~.

test-config.jam has an effect only in "tools/build/v2/test". Anyway, if you 
haven't heard about it, them you haven't modified it ;-)

> > > I don't know. On Solaris I use a site-config.jam <> than on other
> > > systems like you explained me in a former mail in order to set gcc
> > > options in 64-bit mode (using gcc : : : -m64 -mcpu=v9 ;). The flags
> > > were reported to work while building a project using boost but I stil
> > > have to analyse the full build log in order to find similar ELF errors
> > > within.
> >
> > Okay. For a real quick test you can try building v2/example/hello. If
> > that fails, at least you can get the failed command line and figure out
> > what's wrong there.
>
> Here's the output:
>
> ~/cvsboost/boost/tools/build/v2/example/hello(1:512)$ bjam
> ...found 9 targets...
> ...updating 5 targets...
> MkDir1 bin
> MkDir1 bin/gcc
> MkDir1 bin/gcc/debug
> gcc.compile.c++ bin/gcc/debug/hello.o
> gcc.link bin/gcc/debug/hello
> ld: fatal: file bin/gcc/debug/hello.o: wrong ELF class: ELFCLASS64
> ld: fatal: File processing errors. No output written to
> bin/gcc/debug/hello
> collect2: ld returned 1 exit status
>
> "g++" -g -o "bin/gcc/debug/hello" "bin/gcc/debug/hello.o"
>
> ...failed gcc.link bin/gcc/debug/hello...
> ...failed updating 1 target...
> ...updated 4 targets...
>
>
> And the output of a manual compilation using gcc:
>
> gcc -m64 -mcpu=v9 -o bin/gcc/debug/hello bin/gcc/debug/hello.o -lstdc++
>
> and:
>
> "g++" -m64 -g -o "bin/gcc/debug/hello" "bin/gcc/debug/hello.o"
>
>
> both says Hello!
>
> So it seems that bjam doesn't uses the cflags submited via my
> site-config.jam for the link operation.

Yes, the compile flags and link flags are separate. Try changing "using" to 
read:

using gcc : : : -m64 -mcpu=v9 : -m64 ;

- Volodya