When building from source (after having built the binutils, a bootstrap compiler and a freshly ported Newlib) I configured with $ ../src/configure --prefix=/home/cross/tmp --target=i386-unknown-freebsd4.7 --with-newlib --disable-threads --disable-shared --enable-languages=c,c++,java $ make all install Make produced a number of errors due to missing header files, but when examining the ctype_inline.h header file from i386-unknown-freebsd4.7/libstdc++-v3/include/i386-unknown-freebsd4.7/bits/ctype_inline.h, in the build directory (which is a symlink to libstdc++-v3/config/os/bsd/freebsd/ctype_inline.h in the source directory) I found a rather odd bug: 42 return _M_table[static_cast<unsigned char>(__c)] & __m; 43 else 44 return __istype(__c, __m); 45 } 46 Here, __istype is used, while it might not be defined and a couple of lines later: 56 { 57 #if defined (_CTYPE_S) || defined (__istype) 58 *__vec = __maskrune (*__low, upper | lower | alpha | digit | xdigit 59 | space | print | graph | cntrl | punct | alnum); 60 #else 61 mask __m = 0; Line 57 check whether __istype is defined or not, and in case it isn't, and alternative piece of code is used, but not defining __istype will still break the header file. HTH rlc
Subject: Re: New: bug in ctype_inline.h header file (undefined __istype will break compilation) In article <20030612095704.11170.ronald@landheer.com> you write: > $ ../src/configure [...] --target=i386-unknown-freebsd4.7 --with-newlib [...] > [...] Make produced a number of errors due to missing header files [...] This is not a supported configuration at the moment (this is true for many "UNIX" cross-targets within libstdc++-v3 AFAIK). I have no opinion on whether the above should or should not be supported but we will review any patches posted to the libstdc++ list to improve that situation. For one thing, AFAIK, the libstdc++-v3 configuration method looks at target triple without regard to presence of --with-newlib to decide which configuration files to select. Those selected files clearly use knowledge of the target OS and expect system headers to be present not newlib headers. I.e. if there is a bug, then I suggest it is not in: libstdc++-v3/config/os/bsd/freebsd/ctype_inline.h rather it is in the selection process in: libstdc++-v3/configure* (which should be selecting libstdc++-v3/config/os/newlib/ctype_inline.h et al. in the presence of --with-newlib). Ah, BTW, you thought it was an error to use __istype before checking it to guard the use of another entity called __maskrune. That is not-a-bug (you will have to study the *full* history of /usr/include/ctype.h on freebsd to understand why). Regards, Loren (with both libstdc++-v3 and freebsd maintainer hat on)
Subject: Re: bug in ctype_inline.h header file (undefined __istype will break compilation) Most of your reply has more to do with PR 11171 than with PR 11170 - is that intentional? (PR 11171 notes that the wrong headers are being pulled in; PR 11170 is about the FreeBSD headers and __istype) As for: > Ah, BTW, you thought it was an error to use __istype before checking it > to guard the use of another entity called __maskrune. That is not-a-bug > (you will have to study the *full* history of /usr/include/ctype.h on > freebsd to understand why). I'd love to study the full history of the FreeBSD headers, but I don't currently have the time for that. If you say it's not a bug, that's good enough for me. (but in that case, shouldn't the PR be resolved as "invalid"?) thx rlc On 12 Jun 2003, rittle@latour.rsch.comm.mot.com wrote: > This is not a supported configuration at the moment (this is true for > many "UNIX" cross-targets within libstdc++-v3 AFAIK). I have no > opinion on whether the above should or should not be supported but we > will review any patches posted to the libstdc++ list to improve that > situation. For one thing, AFAIK, the libstdc++-v3 configuration > method looks at target triple without regard to presence of > --with-newlib to decide which configuration files to select. Those > selected files clearly use knowledge of the target OS and expect > system headers to be present not newlib headers. > > I.e. if there is a bug, then I suggest it is not in: > libstdc++-v3/config/os/bsd/freebsd/ctype_inline.h > rather it is in the selection process in: > libstdc++-v3/configure* (which should be selecting > libstdc++-v3/config/os/newlib/ctype_inline.h et al. in the presence > of --with-newlib). > > Ah, BTW, you thought it was an error to use __istype before checking > it to guard the use of another entity called __maskrune. That is > not-a-bug (you will have to study the *full* history of > /usr/include/ctype.h on freebsd to understand why). > > Regards, > Loren (with both libstdc++-v3 and freebsd maintainer hat on) > > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. >
Why do you want to use NewLib instead of FreeBSD's Libc?
Subject: Re: bug in ctype_inline.h header file (undefined __istype will break compilation) On Wed, Aug 06, 2003 at 03:56:54AM -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=11170 > > > pinskia at physics dot uc dot edu changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |WAITING > > > ------- Additional Comments From pinskia at physics dot uc dot edu 2003-08-06 03:56 ------- > Why do you want to use NewLib instead of FreeBSD's Libc? I don't see how that matters, but it's part of the cross-compiling experiments I'm running. Eventually, I'll be using the same kind of setup to cross-compile to AIX and Solaris. rlc
Okay I always through you need to use the OS's libc (or a compatiable one) when building a cross- compiler but I was wrong.
I'm going to close this as WONTFIX. Mostly, because the bug 11171, which deals with --with-newlib, when fixed, will make this one go away. Since it's fixed in 3.4.0 and above, this is largely an issue for 3.3.x. Which, I suppose, should be fixed. -benjamin