Used configuration line: $ ../src/configure --prefix=/home/cross/tmp --target=i386-unknown-freebsd4.7 --with-newlib --disable-threads --disable-shared --enable-languages=c,c++,java When building for FreeBSD (and presumably any other platform that doesn't automagically use Newlib as crt) the FreeBSD headers for ctype (and other OS-specific headers) are used automatically, regardless of whether we're using Newlib or not. The bug is located in configure.target, in the block that starts at: 106 # Set any OS-dependent bits. 107 # Set the os_include_dir. 108 # Set c_model, c_compatibility here. 109 # If atomic ops and/or numeric limits are OS-specific rather than 110 # CPU-specifc, set those here too. 111 # THIS TABLE IS SORTED. KEEP IT THAT WAY. In my particular case, the bug is at: 137 freebsd*) 138 os_include_dir="os/bsd/freebsd" 139 # The FreeBSD ABI is expressed in the major version number only. 140 abi_baseline_triplet=`echo ${target} | sed 's,\(\.[0-9]*\)*$,,'` 141 ;; IMHO, after this table is passed, the --with-newlib option for configure should be re-examined and the os_include_dir should be overridden accordingly. Something like this: if test x"$with_newlib" = "xyes"; then os_include_dir="os/newlib" fi should do nicely. This does require a two-liner in acinclude.m4: AC_ARG_WITH(newlib, [ --with-newlib use newlib]) (in the GLIBCPP_CONFIGURE macro) Stragely enough, the same change is required in configure.in: while the GLIBCPP_CONFIGURE macro is called the block starting at 114 # Construct crosses by hand, eliminating bits that need ld... 115 # GLIBCPP_CHECK_COMPILER_FEATURES 116 # GLIBCPP_CHECK_BUILTIN_MATH_SUPPORT 117 # GLIBCPP_CHECK_MATH_SUPPORT overrides some of the settings. (specifically it overrides the os_include_dir that was set in configure.target). I see no reason to do this twice, but had to include 274 if test x"$with_newlib" = "xyes"; then 275 os_include_dir="os/newlib" 276 fi I'll prepare a patch and send it to gcc-patches. HTH rlc
Patch can be found here: http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01242.html
Confirmed with mainline (20030705).
Wrong component, changing to v3.
Why do you want to use NewLib instead of FreeBSD's libc?
Subject: Re: Wrong ctype/OS include files when using Newlib On Wed, Aug 06, 2003 at 04:01:42AM -0000, pinskia at physics dot uc dot edu wrote: > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11171 > > > pinskia at physics dot uc dot edu changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |WAITING > > > ------- Additional Comments From pinskia at physics dot uc dot edu 2003-08-06 04:01 ------- > Why do you want to use NewLib instead of FreeBSD's libc? Again, I don't see how that matters: it's part of the cross-compilation experiments I'm running. Using another libc is not an option for me. rlc
Correct. Newlib makes cross-compilation more or less painless... Shouldn't be in waiting.
What's the status with this bug? Specifically, with the 3.4.0 code base. -benjamin
Subject: Re: Wrong ctype/OS include files when using Newlib -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bkoz at gcc dot gnu dot org wrote: |------- Additional Comments From bkoz at gcc dot gnu dot org 2004-03-18 20:49 ------- | |What's the status with this bug? Specifically, with the 3.4.0 code base. | |-benjamin | | | I don't know - haven't tested it (yet). I should note that I am no longer "on the case" as I quit from the job for which I was making a cross-compiler at the time. The code I wrote back then is non-open, so I don't have it. To test what the status of this bug is, I would either have to re-write the code I've written (to port Newlib to FreeBSD) or find some other way to reproduce the symptoms. I'll send a message to my former chef. It should be rather trivial to reproduce the bug if it still exists with what I left behind. rlc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAXwxvU1nODpimgXsRAmBuAKCk1bHa4P3QuaHHr1q4uogJgqJk6QCgkqJV TB0QsZZVim5bYMrj5jrkR+4= =txPK -----END PGP SIGNATURE-----
Phil fixed this for 3.4.0 and mainline with the autoconf/automake update. In theory, that patch could be backported to 3.3, although I'm not especially eager to do it. The patch attached could be used, minus the configure.target bits. -benjamin
Subject: Bug 11171 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: bkoz@gcc.gnu.org 2004-05-25 06:05:30 Modified files: libstdc++-v3 : ChangeLog acinclude.m4 aclocal.m4 configure configure.in Log message: 2004-05-24 Ronald Landheer-Cieslak <ronald@landheer.com> PR libstdc++/11171 * acinclude.m4: Deal with --with-newlib. * aclocal.m4: Regenerate. * configure.in: Set os_include_dir correctly when --with-newlib. * configure: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.1464.2.184&r2=1.1464.2.185 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/acinclude.m4.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.223.2.10&r2=1.223.2.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/aclocal.m4.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.235.2.12&r2=1.235.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/configure.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.286.2.21&r2=1.286.2.22 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/configure.in.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.110.2.12&r2=1.110.2.13
Fixed.