>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 >Closed-Date: >Last-Modified: >Originator: Ronald Landheer-Cieslak >Release: current CVS (2003-02-19), 3.2.{1|2} >Organization: >Environment: 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 >Description: 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 >How-To-Repeat: 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 >Fix: 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. >Release-Note: >Audit-Trail: >Unformatted: