runtest vs. multilib.
Robert Lipe
robertl@dgii.com
Fri Sep 19 11:40:00 GMT 1997
I went to repeat my test for g++ on coff (see previous
configuratino information) and found something icky.
I executed:
make check-g++ RUNTESTFLAGS="--tool_opts="-mcoff" --outdir=coff"
A small truckload of test cases failed becuase they couldn't link
against the COFF libio. It turns out that it couldn't link becuase
gcc is too smart for runtest (or vice versa)
Runtest will generate a compile like that looks (whitespace added) like
this:
/play/negcs/gcc/testsuite/../xgcc -B/play/negcs/gcc/testsuite/../ \
-mcoff\
/play/egcs-970917/gcc/testsuite/g++.old-deja/g++.brendan/ptolemy2.C \
-ansi -pedantic-errors \
-I/play/egcs-970917/libio -I/play/negcs/libraries/./libio \
-I/play/libg++ -I/play/libg++/src -I/play/egcs-970917/libstdc++ \
-I/play/egcs-970917/libstdc++/stl \
-I/play/negcs/gcc/testsuite/../include -lstdc++ \
-L/play/negcs/libraries/./libstdc++ \
-L/play/negcs/libraries/./libiberty -lm -o /tmp/a.out
Now, the highly trained multiliberals among you spot the problem
right off the bat. It's looking for the ELF libes (and includes,
but does that matter?) instead of the COFF ones.
This results in failures like:
undefined first referenced
symbol in file
cout /usr/tmp/cca005NF1.o
ostream::operator<<(char const *) /usr/tmp/cca005NF1.o
i386ld fatal: Symbol referencing errors. No output written to /tmp/a.out
collect2: ld returned 13 exit status
Now, if we just run around that command line and replace the dots
with "coff", things work better:
$ diff w w_
5c5
< -I/play/egcs-970917/libio -I/play/negcs/libraries/coff/libio \
---
> -I/play/egcs-970917/libio -I/play/negcs/libraries/./libio \
9,10c9,10
< -L/play/negcs/libraries/coff/libstdc++ \
< -L/play/negcs/libraries/coff/libiberty -lm -o /tmp/a.out
---
> -L/play/negcs/libraries/./libstdc++ \
> -L/play/negcs/libraries/./libiberty -lm -o /tmp/a.out
$ sh w && file /tmp/a.out && /tmp/a.out
/tmp/a.out: iAPX 386 COFF demand-paged executable not stripped
PASS
So, am I just really driving the 'make check' target wrong for
this case, or is there a problem with it? Is there something
wrong with the way we're building this multilib target? Is
this fallout from the failure I mentioned earlier of runtest
not recognizing this as a multilibbed target?
Thanx for all help offered.
RJL
More information about the Gcc
mailing list