other/9755: Code gets compiled that shouldn't be when using Newlib (compiling the compiler)

ronald@landheer.com ronald@landheer.com
Wed Feb 19 14:26:00 GMT 2003

>Number:         9755
>Category:       other
>Synopsis:       Code gets compiled that shouldn't be when using Newlib (compiling the compiler)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 19 14:26:00 UTC 2003
>Originator:     Ronald Landheer-Cieslak
>Release:        current CVS (2003-02-19), 3.2.{1|2}
building a cross-compiler for linux-x-freebsd4.7. uname output for the build system: 
$ uname -a
Linux linux_rln.harvest 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux
When building a cross-compiler for linux-x-freebsd4.7, using Newlib as C run-time library, using the following configuration options
* for gcc bootstrap compiler (in ~/gcc-bootstrap):
$ ../gcc-src/configure --prefix=$HOME/tmp --target=i386-unknown-freebsd4.7 --enable-languages=c --with-newlib --disable-shared --with-local-prefix=$HOME/tmp/i386-unknown-freebsd4.7
environment: PATH='$HOME/tmp/bin:$PATH'
(binutils 2.13.1 already built & installed at the same prefix)
> works fine
building newlib-1.10.0 poses no problem either

building the full compiler (in ~/gcc-full):
$ ../gcc-src/configure --prefix=$HOME/tmp --target=i386-unknown-freebsd4.7 --with-newlib --disable-shared --with-local-prefix=$HOME/tmp/i386-unknown-freebsd4.7 --disable-threads

problem: files get compiled that shouldn't be. The thread that starts at http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01202.html contains more details (and leads to this PR). Generally, for a platform that doesn't have signals, stuff that depends on signals still gets compiled; and for Newlib, the file libjava/java/lang/natPosixProcess.cc should probably not be compiled either
The compile above was tried with versions 3.2.1 and 3.2.2. Both failed at the same point (3.2.1 also failed to build for the two reasons below - I don't remember whether it was the case for 3.2.2).

1) A program called ffitest won't compile – a call to fprintf() produces a reference to _impure_ptr which doesn't exist. I've replaced it with a little script that simply calls true… (even the call to true is useless, but like this, the script at least does something)

FD_ZERO expands to bzero(ptr, sizeof(*ptr)) which needs ptr to be a char*, nothing else. FD_ZERO never will have a char* passed to it, ofcourse, but the compiler doesn't like having to convert it. The fix: change the bzero() call to a memset() call, at the source, in <sys/types.h>
The patch supplied at http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01202.html works around the problem, but doesn't actually fix it.

More information about the Gcc-bugs mailing list