Results for binutils (CVS main branch Mon Feb 18 05:56:31 UTC 2002) testsuite on sparc-unknown-linux-gnu
Daniel Jacobowitz
drow@mvista.com
Mon Feb 18 16:23:00 GMT 2002
On Mon, Feb 18, 2002 at 09:17:10PM +0100, Christian J?nsson wrote:
> On Mon, Feb 18, 2002 at 02:15:32PM -0500, Daniel Jacobowitz wrote:
> > On Mon, Feb 18, 2002 at 07:36:46PM +0100, Christian J?nsson wrote:
> > > This was on a Debian Woody (test release) sun4m system using
> > >
> > > binutils 2.11.92.0.12.3-6
> > > dejagnu 1.4-4
> > > gcc-3.0 3.0.3-1
> > > libc6 2.2.5-3
> > >
> > > /ChJ
> > > LAST_UPDATED: Mon Feb 18 05:56:31 UTC 2002
>
> Note that this was compiled as a part of a gcc-3.1 bootstrap...
>
> > I think I committed the fix for the visibility stuff (which I appear to
> > have botched) just after that time. No, it was just before...
>
> The binutils directory has a time stamp of
>
> Mon Feb 18 05:57:51 UTC 2002
>
> which is about minute later on (it perhaps takes a minute to update
> binutils)...
Your script is a little confused. Are you on a different UTC than I
am?
I'd actually committed something that didn't compile, just fixed. If
you'd actually updated at the time you list above, the entire set of
visibility tests would have been ERRORs.
> 21,22c21,22
> < visibility_checkvarptr () == 0
> < main_visibility_checkvar () == 0
> ---
> > visibility_checkvarptr () == 1
> > main_visibility_checkvar () == 1
> child process exited abnormally
> FAIL: visibility (hidden_weak) (PIC main)
Please try this again. If it persists, something is seriously wrong.
I don't see these.
> > > FAIL: S-records
> > > FAIL: S-records with constructors
> >
> > What's in your logs for this one? You seemed to have a different issue
> > from Jakub.
>
> /share1/gcc-dev/gcc/objdir/gcc/xgcc -B/share1/gcc-dev/gcc/objdir/gcc/ -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-srec -g -fPIC -c /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr1.c -o tmpdir/sr1.o
> /share1/gcc-dev/gcc/objdir/gcc/xgcc -B/share1/gcc-dev/gcc/objdir/gcc/ -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-srec -g -fPIC -c /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr2.c -o tmpdir/sr2.o
> /share1/gcc-dev/gcc/objdir/ld/ld-new -o tmpdir/sr1 -Ttext 0x1000 tmpdir/sr1.o tmpdir/sr2.o
> /share1/gcc-dev/gcc/objdir/ld/ld-new -o tmpdir/sr2.sr -Ttext 0x1000 --oformat srec tmpdir/sr1.o tmpdir/sr2.o
> tmpdir/sr1.o: In function `main':
> /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr1.c:16: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr1.c:17: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> tmpdir/sr2.o: In function `fn1':
> /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr2.c:9: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr2.c:10: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> tmpdir/sr2.o: In function `fn2':
> /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr2.c:16: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> tmpdir/sr2.o:/share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr2.c:17: more undefined references to `_GLOBAL_OFFSET_TABLE_' follow
> FAIL: S-records
> /share1/gcc-dev/gcc/objdir/gcc/g++ -B/share1/gcc-dev/gcc/objdir/gcc/ -nostdinc++ -nostdinc++ -I/share1/gcc-dev/gcc/objdir/sparc-linux/libstdc++-v3/include/sparc-linux -I/share1/gcc-dev/gcc/objdir/sparc-linux/libstdc++-v3/include -I/share1/gcc-dev/gcc/libstdc++-v3/libsupc++ -I/share1/gcc-dev/gcc/libstdc++-v3/libio -I/share1/gcc-dev/gcc/libstdc++-v3/include/backward -I/share1/gcc-dev/gcc/libstdc++-v3/testsuite -L/share1/gcc-dev/gcc/objdir/sparc-linux/libstdc++-v3/src -L/share1/gcc-dev/gcc/objdir/sparc-linux/libstdc++-v3/src/.libs -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -g -O2 -fgnu-linker -fno-exceptions -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-srec -g -fPIC -c /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc -o tmpdir/sr3.o
> /share1/gcc-dev/gcc/objdir/ld/ld-new -o tmpdir/sr1 -Ttext 0x1000 tmpdir/sr3.o
> /share1/gcc-dev/gcc/objdir/ld/ld-new -o tmpdir/sr2.sr -Ttext 0x1000 --oformat srec tmpdir/sr3.o
> tmpdir/sr3.o: In function `main':
> /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:24: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:25: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> tmpdir/sr3.o: In function `Foo::init_foo()':
> /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:87: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:88: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> tmpdir/sr3.o: In function `Foo::Foo()':
> /share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:92: undefined reference to `_GLOBAL_OFFSET_TABLE_'
> tmpdir/sr3.o:/share1/gcc-dev/gcc/ld/testsuite/ld-srec/sr3.cc:93: more undefined references to `_GLOBAL_OFFSET_TABLE_' follow
> FAIL: S-records with constructors
I don't see these, either, which is quite odd.
What exactly is your configure command?
> /share1/gcc-dev/gcc/objdir/gcc/xgcc -B/share1/gcc-dev/gcc/objdir/gcc/ -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -S -g -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-elfvers -g -fpic -c /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers3.c -o tmpdir/vers3.s
xgcc is gcc 3.1 there, I assume? Binutils is what, 2.12 branch? CVS
head?
> /share1/gcc-dev/gcc/objdir/ld/../gas/as-new -o tmpdir/vers3.o tmpdir/vers3.s
> /share1/gcc-dev/gcc/objdir/ld/ld-new -m elf32_sparc -o tmpdir/vers3 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o ../gcc/crtbegin.o tmpdir/vers3.o tmpdir/vers1.so ../gcc/libgcc.a -L/usr/lib -lc ../gcc/libgcc.a ../gcc/crtend.o /usr/lib/crtn.o
> tmpdir/vers3.o: In function `main':
> /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers3.c:11: relocation truncated to fit: R_SPARC_13 .rodata
> FAIL: vers3
> /share1/gcc-dev/gcc/objdir/gcc/xgcc -B/share1/gcc-dev/gcc/objdir/gcc/ -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -S -g -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-elfvers -g -fpic -c /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers4.c -o tmpdir/vers4.s
> /share1/gcc-dev/gcc/objdir/ld/../gas/as-new -o tmpdir/vers4.o tmpdir/vers4.s
> /share1/gcc-dev/gcc/objdir/ld/ld-new -m elf32_sparc -o tmpdir/vers4 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o ../gcc/crtbegin.o tmpdir/vers4.o ../gcc/libgcc.a -L/usr/lib -lc ../gcc/libgcc.a ../gcc/crtend.o /usr/lib/crtn.o
> tmpdir/vers4.o: In function `main':
> /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers4.c:29: relocation truncated to fit: R_SPARC_13 .rodata
> FAIL: vers4
> /share1/gcc-dev/gcc/objdir/gcc/xgcc -B/share1/gcc-dev/gcc/objdir/gcc/ -B/usr/local/sparc-linux/bin/ -B/usr/local/sparc-linux/lib/ -isystem /usr/local/sparc-linux/include -L/share1/gcc-dev/gcc/objdir/ld -S -g -B/share1/gcc-dev/gcc/objdir/ld/tmpdir/gas/ -I/share1/gcc-dev/gcc/ld/testsuite/ld-elfvers -g -fpic -c /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers4.c -o tmpdir/vers4a.s
> /share1/gcc-dev/gcc/objdir/ld/../gas/as-new -o tmpdir/vers4a.o tmpdir/vers4a.s
> /share1/gcc-dev/gcc/objdir/ld/ld-new -m elf32_sparc -o tmpdir/vers4a -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o ../gcc/crtbegin.o -export-dynamic tmpdir/vers4a.o ../gcc/libgcc.a -L/usr/lib -lc ../gcc/libgcc.a ../gcc/crtend.o /usr/lib/crtn.o
> tmpdir/vers4a.o: In function `main':
> /share1/gcc-dev/gcc/ld/testsuite/ld-elfvers/vers4.c:29: relocation truncated to fit: R_SPARC_13 .rodata
> FAIL: vers4a
I've no idea at all where this is coming from.
> So, that's that. Why don't I test build binutils 2.12 branch usinf
> gcc-3.0.3 and submit those results and we'll look into that?
Please do.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
More information about the Binutils
mailing list