correct to set -nostdinc and then include <stdarg.h> ?
I was trying to compile 2.5.66 with gcc 3.2.2. It dies as soon as it tries to compile init/main.c because it is unable to find "stdarg.h" which is included by "include/linux/kernel.h".
The "-nostdinc" flag is set in the compile options. If I remove that flag, that particular file appears to compile fine.
It seems wrong to tell the compiler to not look in the standard places but then include a standard file. Am I missing something?
Other compiler versions work fine, so I'm guessing the compiler now interprets the flag more strictly than before.
What is the proper way to deal with this?
Chris
Signature · 4 lines
Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: [email protected]
Quoted 4 lines · Chris Friesen
I was trying to compile 2.5.66 with gcc 3.2.2. It dies as soon as it tries to compile
init/main.cbecause it is unable to find "stdarg.h" which is included by "include/linux/kernel.h".
Try this:
Index: 66.1/Makefile
Makefile Mon, 07 Apr 2003 15:13:54 +1000 kaos (linux-2.5/I/d/12_Makefile 1.45.1.4.1.59 444) renamed from Makefile Tue, 25 Mar 2003 11:23:27 +1100 kaos (linux-2.5/I/d/12_Makefile 1.45.1.4.1.59 444) +1 -1
@@ -177,7 +177,7 @@ LDFLAGS_MODULE = -r CFLAGS_KERNEL = AFLAGS_KERNEL = -NOSTDINC_FLAGS = -nostdinc -iwithprefix include +NOSTDINC_FLAGS = -nostdinc $(shell LANG=C $(CC) -print-search-dirs | sed -ne 's/install: \(.*\)/-I \1include/gp') CPPFLAGS := -D__KERNEL__ -Iinclude CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
Quoted 6 lines · Keith Owens
Quoted 4 lines · Chris Friesen
I was trying to compile 2.5.66 with gcc 3.2.2. It dies as soon as it tries to compile
init/main.cbecause it is unable to find "stdarg.h" which is included by "include/linux/kernel.h".
stdarg.h is part of the compiler specific includes. We want to pick up on these, so we use "-iwithprefix include" to add the compiler specific includes back.
Unfortunately, there seems to be something wrong with GCC's ability to determine where these includes really reside when GCC is installed in a different location to the one it was configured with. In other words, don't do that. Install GCC to the location where you told it to be installed.
For instance, on a Red Hat machine, try:
# cp /usr/bin/gcc /usr/local/bin # hash -r # touch t.c # gcc -nostdinc -iwithprefix include -v t.c Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs /usr/lib/gcc-lib/i386-redhat-linux/2.96/cpp0 -lang-c -nostdinc -v -iprefix /usr/local/bin/../lib/gcc-lib/i386-redhat-linux/2.96/ -D__GNUC__=2 -D__GNUC_MINOR__=96 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__NO_INLINE__ -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_i386__ -iwithprefix include t.c GNU CPP version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2) (cpplib) (i386 Linux/ELF) ignoring nonexistent directory "/usr/local/lib/gcc-lib/i386-redhat-linux/2.96/include" #include "..." search starts here: End of search list. # rm /usr/local/bin/gcc # hash -r
and note that it fails.
Quoted 3 lines
Try this:
From a quick look at the patch, doesn't this mean that we re-evaluate
the search directory each time we build the compiler? Would it not be better to cache the result ?
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 10 lines · Russell King
Quoted 4 lines · Keith Owens
Quoted 2 lines · Chris Friesen
I was trying to compile 2.5.66 with gcc 3.2.2. It dies as soon as it tries to compile
init/main.cbecause it is unable to find "stdarg.h" which is included by "include/linux/kernel.h".
stdarg.his part of the compiler specific includes. We want to pick up on these, so we use "-iwithprefix include" to add the compiler specific includes back.
It doesn't seem to work with gcc 3.2.2 then.
Quoted 5 lines
Unfortunately, there seems to be something wrong with GCC's ability to determine where these includes really reside when GCC is installed in a different location to the one it was configured with. In other words, don't do that. Install GCC to the location where you told it to be installed.
gcc was configured with a prefix of "/usr/local/gcc322" and installed using "make install". It still gave the error. Is this a gcc bug? I'm at work now, but I can run the command you gave this evening to check the results.
Chris
Signature · 4 lines
Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: [email protected]
Quoted 23 lines · Chris Friesen
Quoted 5 lines · Russell King
Quoted 3 lines · Keith Owens
On Mon, 07 Apr 2003 00:41:22 -0400,
Chris Friesen <[email protected]> wrote:Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
I was trying to compile 2.5.66 with gcc 3.2.2. It dies as soon as it tries to compile
init/main.cbecause it is unable to find "stdarg.h" which is included by "include/linux/kernel.h".
stdarg.his part of the compiler specific includes. We want to pick up on these, so we use "-iwithprefix include" to add the compiler specific includes back.It doesn't seem to work with gcc 3.2.2 then.
Quoted 5 lines
Unfortunately, there seems to be something wrong with GCC's ability to determine where these includes really reside when GCC is installed in a different location to the one it was configured with. In other words, don't do that. Install GCC to the location where you told it to be installed.
Quoted 5 lines
gcc was configured with a prefix of "
/usr/local/gcc322" and installed using "make install". It still gave the error. Is this a gcc bug? I'm at work now, but I can run the command you gave this evening to check the results.
It does work fine. I for instance have gcc binary in /usr/i686-pc-linux-gnu/gcc-bin/3.2 and the libraries in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2, which works fine.
You might just have to give --bindir, etc to the exact locations. Also, make sure you do not have symlinks, etc in /usr/bin, as they sometimes 'confuses' gcc ...
Signature · 1 line
Martin Schlemmer
Quoted 3 lines · Martin Schlemmer
You might just have to give --bindir, etc to the exact locations. Also, make sure you do not have symlinks, etc in
/usr/bin, as they sometimes 'confuses' gcc ...
Hmm...maybe that's it. I've got /usr/local/bin/gcc322 symlinked to /usr/local/gcc322/bin/gcc. The equivalent link works with gcc 2.95.3 though...
Chris
Signature · 4 lines
Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: [email protected]
Quoted 9 lines · Chris Friesen
Quoted 3 lines · Martin Schlemmer
You might just have to give --bindir, etc to the exact locations. Also, make sure you do not have symlinks, etc in
/usr/bin, as they sometimes 'confuses' gcc ...Hmm...maybe that's it. I've got
/usr/local/bin/gcc322symlinked to/usr/local/gcc322/bin/gcc. The equivalent link works with gcc 2.95.3 though...
It'll work again with GCC 3.4, IIRC. But 3.2 and the upcoming 3.3 release have problems with symlinks.
Signature · 2 lines
Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer