Date: Sat, 21 Sep 2002 03:59:36 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Archie Cobbs <archie@dellroad.org> Cc: Soeren Schmidt <sos@spider.deepcore.dk>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/lib/libc/alpha/gen infinity.c src/lib/libc/i386/gen infinity.c src/lib/libc/ia64/gen infinity.c src/lib/libc/sparc64/gen infinity.c src/lib/msun/src math.h Message-ID: <20020921034528.Q7158-100000@gamplex.bde.org> In-Reply-To: <200209201539.g8KFdU4t065936@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Sep 2002, Archie Cobbs wrote: > Soeren Schmidt writes: > > It seems Archie Cobbs wrote: > > > archie 2002/09/19 12:47:27 PDT > > > > > > Modified files: > > > lib/libc/alpha/gen infinity.c > > > lib/libc/i386/gen infinity.c > > > lib/libc/ia64/gen infinity.c > > > lib/libc/sparc64/gen infinity.c > > > lib/msun/src math.h > > > Log: > > > Fix a problem with the definition of HUGE_VAL causing the gcc warning > > > "cast increases required alignment of target type" on some platforms. > > > > This breaks world here: > > > > cc -O -pipe -march=athlon -DLIBC_MAJOR=5 -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -D__DBINTERFACE_PRIVATE -DINET6 -I/u1/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -DYP -DHESIOD -c /usr/src/lib/libc/i386/gen/infinity.c -o infinity.o > > /usr/src/lib/libc/i386/gen/infinity.c:11: variable `__infinity' has initializer but incomplete type > > Ugh.. my apologies. Unfortunately I'm not sure how to fix this. > It appears there are two versions of "math.h" in the tree (why?): > > src/include/math.h > src/lib/msun/src/math.h > > The 'infinity.c' files are part of libc, yet __infinity is declared > in src/lib/msun/src/math.h, which is the one I changed.. I don't get it. > The src/lib/*/gen/infinity.c files should be including the msun version > of math.h it seems. I thought this was a gcc bug (broken support for using the right path for cross compiling) at first, but it seems to be just foot-shooting using too many -I paths. The -I's in the above cc command are: -I/usr/src/lib/libc/include # OK -I/usr/src/lib/libc/../../include # this spams the main include path # (to the installed includes) -I/u1/obj/usr/src/lib/libc # OK -I/usr/src/lib/libc/../libc/locale # OK So the should-be-unused math.h in src/include/math.h gets used. (This header was used by the CSRG libm and is kept around because it still does some things better.) The fix should be to not use src-relative -I's. I've noticed that there are some new ones pointing to src/sys now. These were all removed because they might cause problems like this. They only help for half-baked cross-compiling without using buildworld on systems where the installed includes are not right but the crossover is small enough for src-relative includes from selected directories combined with the installed includes to work right. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020921034528.Q7158-100000>