I'm unable to build the 2.5.52 SGI kernel. The problem appears to be that Makefile is using the following hack to find gcc's own include files (a lot of trouble to get stdarg.h, but whatever...) NOSTDINC_FLAGS = -nostdinc -iwithprefix include which seems to assume that --iprefix is going to be /usr/lib/<gcc-etc-etc>. This is apparently not the case in my build (see below). I haven't screwed around with /etc/env.d/gcc. The gcc docs specifically discourage use of --iprefix and related, so perhaps that's the real problem here... but anyways, either the Gentoo build [3.2.1-r6] is broken, or I need to hack the kernel Makefile and file a patch there. Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/specs Configured with: /var/tmp/portage/gcc-3.2.1-r6/work/gcc-3.2.1/configure --prefix=/usr --bindir=/usr/i586-pc-linux-gnu/gcc-bin/3.2 --datadir=/usr/share/gcc-data/i586-pc-linux-gnu/3.2 --mandir=/usr/share/gcc-data/i586-pc-linux-gnu/3.2/man --infodir=/usr/share/gcc-data/i586-pc-linux-gnu/3.2/info --enable-shared --host=i586-pc-linux-gnu --target=i586-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,ada,f77,objc,java --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --disable-nls Thread model: posix gcc version 3.2.1 20021207 (Gentoo Linux 3.2.1-20021207)
If you ask me, then the Makefile is broken. Gcc should find by default its include files in /usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/include, and the Makefile should not try to figure out where they are. -r6 of gcc builds everything else on my and many other people's systems, no hacking. I will however have a look at --iprefix, and see if it breaks things or not.
What does the followint give: $ gcc -print-search-includes
I assume the --nostdincl is stopping gcc from using its include files, and the -iwithprefix hack is a (bad) way of trying to get around this. It appears the intent is to not use the system /usr/include stuff, but still use the /usr/lib/gcc... stuff. Using any include file from outside the kernel tree seems like a terrible idea, but that's what they are up to. #gcc -print-search-includes gcc: unrecognized option `-print-search-includes' gcc: no input files
Err, 6am again :P Rather make that: $ gcc -print-search-dirs
Created attachment 6795 [details] gcc-3.2.1-r6.ebuild If you want to, copy this over your copy in portage, remerge gcc-3.2.1-r6, and please check if it fixes the problem gcc side.
gilgamesh:~[1]gcc -print-search-dirs install: /usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/ programs: =/usr/bin/../../lib/gcc-lib/i586-pc-linux-gnu/3.2.1/:/usr/bin/../../lib/gcc-lib/:/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/:/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/:/usr/lib/gcc-lib/i586-pc-linux-gnu/:/usr/lib/gcc/i586-pc-linux-gnu/3.2.1/:/usr/lib/gcc/i586-pc-linux-gnu/:/usr/bin/../../lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../../i586-pc-linux-gnu/bin/i586-pc-linux-gnu/3.2.1/:/usr/bin/../../lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../../i586-pc-linux-gnu/bin/:/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../../i586-pc-linux-gnu/bin/i586-pc-linux-gnu/3.2.1/:/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../../i586-pc-linux-gnu/bin/ libraries: =/usr/bin/../../lib/gcc-lib/i586-pc-linux-gnu/3.2.1/:/usr/bin/../../lib/gcc-lib/:/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/:/usr/lib/gcc/i586-pc-linux-gnu/3.2.1/:/usr/bin/../../lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../../i586-pc-linux-gnu/lib/i586-pc-linux-gnu/3.2.1/:/usr/bin/../../lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../../i586-pc-linux-gnu/lib/:/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../../i586-pc-linux-gnu/lib/i586-pc-linux-gnu/3.2.1/:/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../../i586-pc-linux-gnu/lib/:/usr/bin/../../lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../i586-pc-linux-gnu/3.2.1/:/usr/bin/../../lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../:/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../i586-pc-linux-gnu/3.2.1/:/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/../../../:/lib/i586-pc-linux-gnu/3.2.1/:/lib/:/usr/lib/i586-pc-linux-gnu/3.2.1/:/usr/lib/ gilgamesh:~[1] formatting's pretty bad... I'll email it if it doesn't come thru OK. 6am... you must be in Euroland.. im Deutch, I reckon... just so you know, I'm a Green activist, not with the warmonger crowd... I copied your attachment, will emerge gcc, check it out. I'm heating the place with a k6-2/550, so it will be a while before it's done. Cheers...
Created attachment 6807 [details] ebuild I rebuilt with (for verification) emerge with the ebuild finished. Results in kernel 2.5.52 same: can't find stdarg.h. `gcc -v` still showing '--prefix=/usr'.
Well, I still do not really see the point to --prefix ... if you ran 'gcc -v' with gcc-3.2.1, it will also tell you '--prefix=/usr'. There was also a similar issue on the mailing lists, and openmosix-sources-2.4.20-r1. It build fine here. Thus I think it will be easier for me if you can attach detailed instructions how you build that kernel, and also the config used. I can then try to figure it out myself. BTW: in South Africa, not Euroland =)
OK, South Africa. Lots warmer there than here, I reckon. Good morning/afternoon/evening. :) I see we're on at the same time. I just collided with you in bugzilla (see below). As for the whole question of using -iprefix, and using any .h files outside of the kernel tree, my opinion is Bad Idea. But I'm just trying to get the thing to build. If you decide our gcc isn't broken, and should be using a prefix of /usr instead of <gcc-root>, I'll submit a kernel bug report instead. It seems pretty clear that the kernel Makefile hackers are expecting -iprefix to be the gcc install dir, and this must be building on non-Gentoo systems, unless there is already a patch that SGI hasn't picked up yet. Maybe you should bring whoever the Gentoo development kernel wrangler is in on this for a consult. Two Workarounds: The following Makefile hack makes 2.5.52 build: #NOSTDINC_FLAGS = -nostdinc -iwithprefix include NOSTDINC_FLAGS = -nostdinc -iprefix \ $(shell gcc-config --get-lib-path)/ -iwithprefix include and is included here only for demonstration purposes. The following, while extremely hideous, should actually be non-Gentoo-specific, and also works: NOSTDINC_FLAGS = -nostdinc -iprefix \ $(shell gcc -print-search-dirs|head -1|\ sed -e 's/install[^\/]*//') -iwithprefix include
Ok, let me show with an crude test. Following 'should' show that '-nostdinc -iwithprefix include' does indeed manage to include stdarg.h. I thus do not know if its something else they set, or the like. BTW, what CFLAGS and CXXFLAGS do you use ? And what glibc ? --------------------------------- nosferatu gnome # cat test.c #ifdef _STDARG_H #error 1: _STDARG_H are defined! #endif #include <stdarg.h> #ifdef _STDARG_H #error 2: _STDARG_H are defined! #endif int main() { } nosferatu gnome # gcc -nostdinc -iwithprefix include -c test.c test.c:8:2: #error 2: _STDARG_H are defined! nosferatu gnome #
Broken here: gilgamesh:~[2]gcc xxx.c xxx.c:8:2: #error 2: _STDARG_H are defined! gilgamesh:~[2]gcc -nostdinc -iwithprefix include xxx.c xxx.c:5:20: no include path in which to find stdarg.h I wonder if maybe the recent brokenness of emerge (failing to make symlinks) might be involved in this. CFLAGS? None, other than what's in make.conf. gilgamesh:~[2]export declare -x CC="gcc" declare -x CLASSPATH="/opt/blackdown-jre-1.3.1/lib/rt.jar:." There is some brokenness with glibc, as the glibc info stuff disappeared after the last build (probably the portage bug). Version: * sys-libs/glibc Latest version available: 2.3.1-r2 Latest version installed: 2.3.1-r2
Hmm. Include info from: # emerge info Thanks.
gilgamesh:~[3]emerge info Portage 2.0.46-r4 (default-x86-1.4, gcc-3.2.1, glibc-2.3.1-r2) ================================================================= System uname: 2.4.19-gentoo-r10 i586 AMD-K6(tm) 3D processor USE="x86 oss avi crypt cups encode gif jpeg libg++ libwww mikmod mpeg ncurses pdflib png qtmt quicktime spell truetype xml2 xmms xv zlib gtkhtml gdbm berkdb slang readline bonobo svga tcltk java guile X sdl gpm tcpd pam ssl perl python imlib oggvorbis motif mozilla cdr acpi gtk gnome alsa mmx 3dnow opengl -apm -postgres -dvd -arts -esd -kde -qt -nls" ARCH="x86" COMPILER="gcc3" CHOST="i586-pc-linux-gnu" CFLAGS="-march=k6-2 -mmmx -m3dnow -O3 -pipe" CXXFLAGS="-march=k6-2 -mmmx -m3dnow -O3 -pipe" ACCEPT_KEYWORDS="x86 ~x86" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/kde/3/share/config:/usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" MAKEOPTS="-j2" JDK_HOME="" JAVA_HOME="/opt/blackdown-jre-1.3.1" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" GENTOO_MIRRORS="http://www.ibiblio.org/pub/Linux/distributions/gentoo"
Sorry, festive season, etc. Can you maybe try with CFLAGS="-march=i686 -O2 -pipe" ? I had another mail with similar problems, and this fixed it for him (after remerging gcc with those CFLAGS and CXXFLAGS ...).
Sorry, was on crack. Can you try i586 ?
Ok, seems like it could be fixed with gcc-config-1.3.1. Give it a bash, and let me know.
I did gcc builds with various non-k6 options with no luck, but did a build with * sys-devel/gcc-config Latest version available: 1.3.1 Latest version installed: 1.3.0 * sys-devel/gcc Latest version available: 3.2.1-r7 Latest version installed: 3.2.1-r7 and it works. I haven't tried the new gcc out to see if the k6 support is fixed. Apparently it is known to be bad, as I've seen with xmms (http://bugs.gentoo.org/show_bug.cgi?id=12735) and with some other multimedia stuff. Neither gentoo nor gcc bugzilla have open k6 bugs last time I checked; maybe one should be made. It would be nice to have the k6 optimisations working.
