public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* other/9755: Code gets compiled that shouldn't be when using Newlib (compiling the compiler)
@ 2003-02-19 14:26 ronald
  0 siblings, 0 replies; only message in thread
From: ronald @ 2003-02-19 14:26 UTC (permalink / raw)
  To: gcc-gnats

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]


>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 <sys/types.h>
>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:


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2003-02-19 14:26 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-19 14:26 other/9755: Code gets compiled that shouldn't be when using Newlib (compiling the compiler) ronald

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).