This is the mail archive of the
mailing list for the Cygwin project.
Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8
On Thu, Jul 11, 2002 at 06:17:51AM -0700, Nicholas Wourms wrote:
>--- Christopher Faylor <firstname.lastname@example.org> wrote:
>When I do gcc -v, gcc prints out the following:
>Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.1.1/specs
>Configured with: /netrel/src/gcc-3.1.1-2/configure
>--enable-languages=c,c++,f77,java --enable-libgcj --enable-threads=posix
>--with-system-zlib --enable-nls --without-included-gettext
>--disable-shared --enable-interpreter --disable-sjlj-exceptions
>--host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr
>--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
>--includedir=/nonexistent/include --libexecdir=/usr/sbin :
>Thread model: posix
>gcc version 3.1.1 20020710 (prerelease)
>Shouldn't that be /usr/include? The only reason I ask is because I'm
>quite certain that this could cause troubl in configure scripts. Like
>I've noticed that if I don't explicitly pass CPPFLAGS="-I/usr/include" to
>my configure scripts, they'll miss the limits.h in /usr/include and use
>the one in /usr/lib/gcc-lib/...../include/ instead. This goes for some
>other header detection as well. I believe it is due to the compiler's
>internal search paths. Just thought I'd report that observation.
This is basically the same configure script that I have been using for
two years, so I doubt that it will cause problems.
The limits.h file in /usr/lib/gcc-lib/../include/ *is* the one that is
supposed to be used. It includes the /usr/include/limits.h file
Are you saying that when I announced that the limits.h problem was
fixed, I was wrong? I specifically checked the -E output from a
program and saw that /usr/include/limits.h was pulled in specifically.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html