From: Vincent Jamart (vincent.jamart_at_[hidden])
Date: 2004-09-21 08:27:09
On Tue, 2004-09-21 at 13:18, Vladimir Prus wrote:
> > raise "Don't know directory where jam is build for this system: " +
> > os.name + "/" + os.uname()
> > Don't know directory where jam is build for this system: posix/AIX
> 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/
> > 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.
> > > > -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.
> > > > -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 ~.
Anyway, I removed the line from user-config.jam so we'll see.
> > > > -Solaris9/gcc 3.3.1 (64bit)
> > >
> > > Here, there's a lot of errors like:
> > >
> > > ld: fatal: file bin/gcc/debug/a.o: wrong ELF class: ELFCLASS64
> > >
> > > What could be wrong? Does ld needs some switch to operate in 64-bit mode?
> > 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:
...found 9 targets...
...updating 5 targets...
ld: fatal: file bin/gcc/debug/hello.o: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to
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++
"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.
> - Volodya
> Yahoo! Groups Links
-- ---------------------------------------------------- Vincent Jamart - Free Field Technologies Quality & Systems manager 16 place de l'Universite B-1348 Louvain-la-Neuve - BELGIUM Tel: +32 10 45 12 26 Fax: +32 10 45 46 26 Mobile: +32 495 21 22 58 mailto:vincent.jamart_at_[hidden] http://www.fft.be ----------------------------------------------------
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk