* Does kernel use system stdarg.h? @ 2002-09-27 12:58 Denis Vlasenko 2002-09-27 8:26 ` Russell King [not found] ` <20020927140302.B13401@flint.arm.linux.org.uk> 0 siblings, 2 replies; 14+ messages in thread From: Denis Vlasenko @ 2002-09-27 12:58 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel make[3]: Entering directory `/usr/src/linux-2.5.36/kernel' gcc -E -Wp,-MD,/usr/src/linux-2.5.36/include/linux/modules/kernel/.exec_domain.ver.d -D__KERNEL__ -I/usr/src/linux-2.5.36/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i486 -nostdinc -iwithprefix include -DKBUILD_BASENAME=exec_domain -D__GENKSYMS__ exec_domain.c | /sbin/genksyms -p smp_ -k 2.5.36 > /usr/src/linux-2.5.36/include/linux/modules/kernel/exec_domain.ver.tmp In file included from exec_domain.c:12: /usr/src/linux-2.5.36/include/linux/kernel.h:10:20: stdarg.h: No such file or directory There is no stdarg.h in kernel tree, should it be there? For now I just copied GCC one into linux/include... -- vda ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-27 12:58 Does kernel use system stdarg.h? Denis Vlasenko @ 2002-09-27 8:26 ` Russell King 2002-09-27 13:20 ` Denis Vlasenko 2002-09-27 17:18 ` Denis Vlasenko [not found] ` <20020927140302.B13401@flint.arm.linux.org.uk> 1 sibling, 2 replies; 14+ messages in thread From: Russell King @ 2002-09-27 8:26 UTC (permalink / raw) To: Denis Vlasenko; +Cc: Linus Torvalds, linux-kernel On Fri, Sep 27, 2002 at 10:58:52AM -0200, Denis Vlasenko wrote: > make[3]: Entering directory `/usr/src/linux-2.5.36/kernel' > gcc -E > -Wp,-MD,/usr/src/linux-2.5.36/include/linux/modules/kernel/.exec_domain.ver.d > -D__KERNEL__ -I/usr/src/linux-2.5.36/include -Wall -Wstrict-prototypes > -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common > -pipe -mpreferred-stack-boundary=2 -march=i486 -nostdinc -iwithprefix include > -DKBUILD_BASENAME=exec_domain -D__GENKSYMS__ exec_domain.c | > /sbin/genksyms -p smp_ -k 2.5.36 > > /usr/src/linux-2.5.36/include/linux/modules/kernel/exec_domain.ver.tmp > In file included from exec_domain.c:12: > /usr/src/linux-2.5.36/include/linux/kernel.h:10:20: stdarg.h: No such file or > directory > > There is no stdarg.h in kernel tree, should it be there? > For now I just copied GCC one into linux/include... It must be the GCC one. If your GCC isn't finding it, then you've got a broken GCC installation; "-iwithprefix include" tells GCC to look in its private include directory for such things. You could try adding -v to CFLAGS to see where it is searching for includes. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-27 8:26 ` Russell King @ 2002-09-27 13:20 ` Denis Vlasenko 2002-09-27 9:31 ` Mikael Pettersson 2002-09-27 17:18 ` Denis Vlasenko 1 sibling, 1 reply; 14+ messages in thread From: Denis Vlasenko @ 2002-09-27 13:20 UTC (permalink / raw) To: Russell King; +Cc: linux-kernel On 27 September 2002 06:26, Russell King wrote: > > There is no stdarg.h in kernel tree, should it be there? > > For now I just copied GCC one into linux/include... > > It must be the GCC one. If your GCC isn't finding it, then you've got a > broken GCC installation; "-iwithprefix include" tells GCC to look in its > private include directory for such things. > > You could try adding -v to CFLAGS to see where it is searching for > includes. Oh, I thought we don't depend on any system/GCC headers. :-( -- vda ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-27 13:20 ` Denis Vlasenko @ 2002-09-27 9:31 ` Mikael Pettersson 0 siblings, 0 replies; 14+ messages in thread From: Mikael Pettersson @ 2002-09-27 9:31 UTC (permalink / raw) To: vda; +Cc: Russell King, linux-kernel Denis Vlasenko writes: > On 27 September 2002 06:26, Russell King wrote: > > > There is no stdarg.h in kernel tree, should it be there? > > > For now I just copied GCC one into linux/include... > > > > It must be the GCC one. If your GCC isn't finding it, then you've got a > > broken GCC installation; "-iwithprefix include" tells GCC to look in its > > private include directory for such things. > > > > You could try adding -v to CFLAGS to see where it is searching for > > includes. > > Oh, I thought we don't depend on any system/GCC headers. :-( GCC headers != glibc headers GCC's headers are needed for stdarg and other stuff requiring compiler magic. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-27 8:26 ` Russell King 2002-09-27 13:20 ` Denis Vlasenko @ 2002-09-27 17:18 ` Denis Vlasenko 2002-09-27 14:05 ` Daniel Jacobowitz 1 sibling, 1 reply; 14+ messages in thread From: Denis Vlasenko @ 2002-09-27 17:18 UTC (permalink / raw) To: linux-kernel On 27 September 2002 06:26, Russell King wrote: > On Fri, Sep 27, 2002 at 10:58:52AM -0200, Denis Vlasenko wrote: > > make[3]: Entering directory `/usr/src/linux-2.5.36/kernel' > > gcc -E > > -Wp,-MD,/usr/src/linux-2.5.36/include/linux/modules/kernel/.exec_domain.v > >er.d -D__KERNEL__ -I/usr/src/linux-2.5.36/include -Wall > > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer > > -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 > > -march=i486 -nostdinc -iwithprefix include -DKBUILD_BASENAME=exec_domain > > -D__GENKSYMS__ exec_domain.c | /sbin/genksyms -p smp_ -k 2.5.36 > > > /usr/src/linux-2.5.36/include/linux/modules/kernel/exec_domain.ver.tmp > > In file included from exec_domain.c:12: > > /usr/src/linux-2.5.36/include/linux/kernel.h:10:20: stdarg.h: No such > > file or directory > > > > There is no stdarg.h in kernel tree, should it be there? > > For now I just copied GCC one into linux/include... > > It must be the GCC one. If your GCC isn't finding it, then you've got a > broken GCC installation; "-iwithprefix include" tells GCC to look in its > private include directory for such things. > > You could try adding -v to CFLAGS to see where it is searching for > includes. This is funny. t.c === #include <stdarg.h> int main() { return 0; } # gcc t.c # ./a.out (runs okay) So it works this way. But gcc invocation from kernel compile does not work. Here is its output with -v: --------------------------- Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs Configured with: ../gcc-3.0.3/configure --prefix=/usr/app/gcc-3.0.3posix --exec-prefix=/usr/app/gcc-3.0.3posix --bindir=/usr/app/gcc-3.0.3posix/bin --libdir=/usr/lib --infodir=/usr/app/gcc-3.0.3posix/info --mandir=/usr/app/gcc-3.0.3posix/man --with-slibdir=/usr/lib --with-local-prefix=/usr/local --with-gxx-include-dir=/usr/include/g++-v3 --enable-threads=posix Thread model: posix gcc version 3.0.3 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/cpp0 -lang-c -nostdinc -v ^^^^^^^^^ -I/usr/src/linux-2.5.36/include -iprefix /usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/ -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=3 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Wall -Wstrict-prototypes -Wno-trigraphs -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__i486 -D__i486__ -D__tune_i486__ -D__KERNEL__ -DKBUILD_BASENAME=exec_domain -D__GENKSYMS__ -iwithprefix include -MD /usr/src/linux-2.5.36/include/linux/modules/kernel/.exec_domain.ver.d exec_domain.c ignoring nonexistent directory "/usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/include" GNU CPP version 3.0.3 (cpplib) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/src/linux-2.5.36/include <------ no system/GCC/glibc paths! :-( End of search list. In file included from exec_domain.c:12: /usr/src/linux-2.5.36/include/linux/kernel.h:10:20: stdarg.h: No such file or directory Hmm... lets try gcc -v t.c: --------------------------- Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs Configured with: ../gcc-3.0.3/configure --prefix=/usr/app/gcc-3.0.3posix --exec-prefix=/usr/app/gcc-3.0.3posix --bindir=/usr/app/gcc-3.0.3posix/bin --libdir=/usr/lib --infodir=/usr/app/gcc-3.0.3posix/info --mandir=/usr/app/gcc-3.0.3posix/man --with-slibdir=/usr/lib --with-local-prefix=/usr/local --with-gxx-include-dir=/usr/include/g++-v3 --enable-threads=posix Thread model: posix gcc version 3.0.3 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/cc1 -lang-c -v -iprefix /usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/ -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=3 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ t.c -quiet -dumpbase t.c -version -o /tmp/ccH59JjF.s GNU CPP version 3.0.3 (cpplib) (i386 Linux/ELF) GNU C version 3.0.3 (i686-pc-linux-gnu) compiled by GNU C version 3.0.3. ignoring nonexistent directory "/usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/include" ignoring nonexistent directory "/usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/../../../../i686-pc-linux-gnu/include" ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc-lib/../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/include /usr/include End of search list. as --traditional-format -V -Qy -o /tmp/cc0GhxK1.o /tmp/ccH59JjF.s GNU assembler version 2.11.90.0.8 (i686-pc-linux-gnu) using BFD version 2.11.90.0.8 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/crtbegin.o -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3 -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/../../.. /tmp/cc0GhxK1.o -lgcc -lc -lgcc /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/crtend.o /usr/lib/crtn.o Heh. Kernel one contains -nostdinc! See underlined (^^^^^^) above. Tested it with --nostdinc - it worked. -- vda ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-27 17:18 ` Denis Vlasenko @ 2002-09-27 14:05 ` Daniel Jacobowitz 2002-09-27 21:47 ` Oliver Xymoron 0 siblings, 1 reply; 14+ messages in thread From: Daniel Jacobowitz @ 2002-09-27 14:05 UTC (permalink / raw) To: Denis Vlasenko; +Cc: linux-kernel On Fri, Sep 27, 2002 at 03:18:35PM -0200, Denis Vlasenko wrote: > Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs > Configured with: ../gcc-3.0.3/configure --prefix=/usr/app/gcc-3.0.3posix --exec-prefix=/usr/app/gcc-3.0.3posix --bindir=/usr/app/gcc-3.0.3posix/bin --libdir=/usr/lib --infodir=/usr/app/gcc-3.0.3posix/info --mandir=/usr/app/gcc-3.0.3posix/man --with-slibdir=/usr/lib --with-local-prefix=/usr/local --with-gxx-include-dir=/usr/include/g++-v3 --enable-threads=posix > Thread model: posix > gcc version 3.0.3 > /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/cpp0 -lang-c -nostdinc -v > ^^^^^^^^^ That's not the problem. > -I/usr/src/linux-2.5.36/include > -iprefix /usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/ That's the problem. Where's the -iprefix coming from? Your configure doesn't specify /usr/sbin anywhere. Verdict: bad GCC install or a 3.0.3 bug. Might have to do with your libdir-outside-of-prefix. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-27 14:05 ` Daniel Jacobowitz @ 2002-09-27 21:47 ` Oliver Xymoron 2002-09-28 8:15 ` Russell King 0 siblings, 1 reply; 14+ messages in thread From: Oliver Xymoron @ 2002-09-27 21:47 UTC (permalink / raw) To: Daniel Jacobowitz, Denis Vlasenko, linux-kernel On Fri, Sep 27, 2002 at 10:05:43AM -0400, Daniel Jacobowitz wrote: > On Fri, Sep 27, 2002 at 03:18:35PM -0200, Denis Vlasenko wrote: > > Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs > > Configured with: ../gcc-3.0.3/configure --prefix=/usr/app/gcc-3.0.3posix --exec-prefix=/usr/app/gcc-3.0.3posix --bindir=/usr/app/gcc-3.0.3posix/bin --libdir=/usr/lib --infodir=/usr/app/gcc-3.0.3posix/info --mandir=/usr/app/gcc-3.0.3posix/man --with-slibdir=/usr/lib --with-local-prefix=/usr/local --with-gxx-include-dir=/usr/include/g++-v3 --enable-threads=posix > > Thread model: posix > > gcc version 3.0.3 > > /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/cpp0 -lang-c -nostdinc -v > > ^^^^^^^^^ > > That's not the problem. > > > -I/usr/src/linux-2.5.36/include > > -iprefix /usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/ > > That's the problem. Where's the -iprefix coming from? Your configure > doesn't specify /usr/sbin anywhere. > > Verdict: bad GCC install or a 3.0.3 bug. Might have to do with your > libdir-outside-of-prefix. I've got the same problem with -nostdinc with my Debian gcc-3.0 that I've been patching around. I assumed it was a problem with the kernel's Makefile, now you're saying it's the Debian package? -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-27 21:47 ` Oliver Xymoron @ 2002-09-28 8:15 ` Russell King 2002-09-28 9:34 ` Alan Cox ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Russell King @ 2002-09-28 8:15 UTC (permalink / raw) To: Oliver Xymoron; +Cc: Daniel Jacobowitz, Denis Vlasenko, linux-kernel On Fri, Sep 27, 2002 at 04:47:22PM -0500, Oliver Xymoron wrote: > > > -I/usr/src/linux-2.5.36/include > > > -iprefix /usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/ > > > > That's the problem. Where's the -iprefix coming from? Your configure > > doesn't specify /usr/sbin anywhere. > > > > Verdict: bad GCC install or a 3.0.3 bug. Might have to do with your > > libdir-outside-of-prefix. > > I've got the same problem with -nostdinc with my Debian gcc-3.0 that > I've been patching around. I assumed it was a problem with the > kernel's Makefile, now you're saying it's the Debian package? It certainly looks like it. gcc 3.0.3 appears to ignore "-iwithprefix include", where as gcc 2.95.x, 2.96, 3.1 and 3.2 all work as expected. -iwithprefix is supposed to add /usr/lib/gcc-lib/<target>/<version>/include to the compilers include path. For curiositys sake, what does: gcc -print-file-name=include give you? That should (in theory) be the same path as -iwithprefix include but iirc this method apparantly breaks with internationalisation (discovered in 2.4.) I'm going to place my bets on: /usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/include though, which would be wrong. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-28 8:15 ` Russell King @ 2002-09-28 9:34 ` Alan Cox 2002-09-28 10:59 ` Tomas Szepe 2002-09-28 15:13 ` Oliver Xymoron 2 siblings, 0 replies; 14+ messages in thread From: Alan Cox @ 2002-09-28 9:34 UTC (permalink / raw) To: Russell King Cc: Oliver Xymoron, Daniel Jacobowitz, Denis Vlasenko, linux-kernel On Sat, 2002-09-28 at 09:15, Russell King wrote: > It certainly looks like it. gcc 3.0.3 appears to ignore > "-iwithprefix include", where as gcc 2.95.x, 2.96, 3.1 and 3.2 all > work as expected. Thats ok. For x86 at least using 3.0.x isnt wise (it occasionally spills data below the stack pointer which means an IRQ at the wrong moment has dire consequences) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-28 8:15 ` Russell King 2002-09-28 9:34 ` Alan Cox @ 2002-09-28 10:59 ` Tomas Szepe 2002-09-28 17:26 ` Russell King 2002-09-28 15:13 ` Oliver Xymoron 2 siblings, 1 reply; 14+ messages in thread From: Tomas Szepe @ 2002-09-28 10:59 UTC (permalink / raw) To: Russell King Cc: Oliver Xymoron, Daniel Jacobowitz, Denis Vlasenko, linux-kernel > > > > -I/usr/src/linux-2.5.36/include > > > > -iprefix /usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/ > > > > > > That's the problem. Where's the -iprefix coming from? Your configure > > > doesn't specify /usr/sbin anywhere. > > > > > > Verdict: bad GCC install or a 3.0.3 bug. Might have to do with your > > > libdir-outside-of-prefix. > > > > I've got the same problem with -nostdinc with my Debian gcc-3.0 that > > I've been patching around. I assumed it was a problem with the > > kernel's Makefile, now you're saying it's the Debian package? > > It certainly looks like it. gcc 3.0.3 appears to ignore > "-iwithprefix include", where as gcc 2.95.x, 2.96, 3.1 and 3.2 all > work as expected. No. Try building/installing gcc-3.2 with '--prefix=/usr/gcc-3.2' and '--prefix=/usr'. The former won't work with '-iwithprefix include', the latter will. GCC build bug? T. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-28 10:59 ` Tomas Szepe @ 2002-09-28 17:26 ` Russell King 2002-09-29 1:16 ` Keith Owens 0 siblings, 1 reply; 14+ messages in thread From: Russell King @ 2002-09-28 17:26 UTC (permalink / raw) To: Tomas Szepe Cc: Oliver Xymoron, Daniel Jacobowitz, Denis Vlasenko, linux-kernel On Sat, Sep 28, 2002 at 12:59:11PM +0200, Tomas Szepe wrote: > > It certainly looks like it. gcc 3.0.3 appears to ignore > > "-iwithprefix include", where as gcc 2.95.x, 2.96, 3.1 and 3.2 all > > work as expected. > > No. Try building/installing gcc-3.2 with '--prefix=/usr/gcc-3.2' > and '--prefix=/usr'. The former won't work with '-iwithprefix include', > the latter will. GCC build bug? Maybe. I've just checked the GCC 3.2 info files, and it appears that the definition of -iwithprefix has changed. gcc 2.9[156] comes with this description: `-iwithprefix DIR' Add a directory to the second include path. The directory's name is made by concatenating PREFIX and DIR, where PREFIX was specified previously with `-iprefix'. If you have not specified a prefix yet, the directory containing the installed passes of the compiler is used as the default. whereas gcc 3.2 comes with: `-iwithprefix DIR' `-iwithprefixbefore DIR' Append DIR to the prefix specified previously with `-iprefix', and add the resulting directory to the include search path. `-iwithprefixbefore' puts it in the same place `-I' would; `-iwithprefix' puts it where `-idirafter' would. Use of these options is discouraged. This seems to leave us with no official guaranteed way to get at the compiler specific includes, which is Bad News(tm). We obviously can't use "-I/usr/lib/gcc-lib/`gcc -dumpmachine`/`gcc -dumpversion`/" and we've already had problems with the 2.4 "gcc -print-search-dirs" version. This leaves us with one option: gcc -print-file-name=include This works, but its also not official: `-print-file-name=LIBRARY' Print the full absolute name of the library file LIBRARY that would be used when linking--and don't do anything else. With this option, GCC does not compile or link anything; it just prints the file name. Maybe we need to go back to the gcc folk and get -iwithprefix reinstated... -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html "I know toolchain people. They _love_ to change things." ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-28 17:26 ` Russell King @ 2002-09-29 1:16 ` Keith Owens 0 siblings, 0 replies; 14+ messages in thread From: Keith Owens @ 2002-09-29 1:16 UTC (permalink / raw) To: linux-kernel On Sat, 28 Sep 2002 18:26:43 +0100, Russell King <rmk@arm.linux.org.uk> wrote: >This seems to leave us with no official guaranteed way to get at the >compiler specific includes, which is Bad News(tm). We obviously can't >use "-I/usr/lib/gcc-lib/`gcc -dumpmachine`/`gcc -dumpversion`/" and >we've already had problems with the 2.4 "gcc -print-search-dirs" >version. LANG=C gcc -print-search-dirs | sed ... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Does kernel use system stdarg.h? 2002-09-28 8:15 ` Russell King 2002-09-28 9:34 ` Alan Cox 2002-09-28 10:59 ` Tomas Szepe @ 2002-09-28 15:13 ` Oliver Xymoron 2 siblings, 0 replies; 14+ messages in thread From: Oliver Xymoron @ 2002-09-28 15:13 UTC (permalink / raw) To: Russell King; +Cc: Daniel Jacobowitz, Denis Vlasenko, linux-kernel On Sat, Sep 28, 2002 at 09:15:30AM +0100, Russell King wrote: > On Fri, Sep 27, 2002 at 04:47:22PM -0500, Oliver Xymoron wrote: > > > > -I/usr/src/linux-2.5.36/include > > > > -iprefix /usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/ > > > > > > That's the problem. Where's the -iprefix coming from? Your configure > > > doesn't specify /usr/sbin anywhere. > > > > > > Verdict: bad GCC install or a 3.0.3 bug. Might have to do with your > > > libdir-outside-of-prefix. > > > > I've got the same problem with -nostdinc with my Debian gcc-3.0 that > > I've been patching around. I assumed it was a problem with the > > kernel's Makefile, now you're saying it's the Debian package? > > It certainly looks like it. gcc 3.0.3 appears to ignore > "-iwithprefix include", where as gcc 2.95.x, 2.96, 3.1 and 3.2 all > work as expected. > > -iwithprefix is supposed to add /usr/lib/gcc-lib/<target>/<version>/include > to the compilers include path. > > For curiositys sake, what does: > > gcc -print-file-name=include > > give you? That should (in theory) be the same path as -iwithprefix include > but iirc this method apparantly breaks with internationalisation > (discovered in 2.4.) I'm going to place my bets on: > > /usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/include /usr/lib/gcc-lib/i386-linux/3.0.4/include Amusingly, I just noticed I already have 3.2.1 on my system as well, which seems to work just fine. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20020927140302.B13401@flint.arm.linux.org.uk>]
* Re: Does kernel use system stdarg.h? [not found] ` <20020927140302.B13401@flint.arm.linux.org.uk> @ 2002-09-30 12:58 ` Denis Vlasenko 0 siblings, 0 replies; 14+ messages in thread From: Denis Vlasenko @ 2002-09-30 12:58 UTC (permalink / raw) To: Russell King, linux-kernel This is slightly offtopic, but since this issue cropped up when I tried to build 2.5 on a box which builds 2.4 just fine I post it here. BTW, if someone knows GCC mailing list addr to send this, please let me know it. [a story about 2.5 kernel not finding stdarg.h snipped] > > > I will try, but it seems to be right behavior - we tell gcc > > > to NOT use standard include places and it does exactly this. > > > So it's not a bug. > > > > No. You missed it. > > > > gcc -nostdic > > ^^^^^^^^ don't use standard includse > > -iwithprefix include > > ^^^^^^^^^^^^^^^^^^^^ but use the specified include path, built out of > > the gcc installation prefix, /usr/lib/gcc-lib/<target>/<version>/ > > aha! my gcc internally adds > -iprefix /usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/ > Dunno where it took this strange idea... I have no such > dir. Anyway, I'll fix my gcc installation. On 27 September 2002 12:05, Daniel Jacobowitz wrote: > > gcc version 3.0.3 > > /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/cpp0 -lang-c -nostdinc -v > > That's not the problem. > > > -I/usr/src/linux-2.5.36/include > > -iprefix /usr/sbin/../../lib/gcc-lib/i686-pc-linux-gnu/3.0.3/ > > That's the problem. Where's the -iprefix coming from? Your configure > doesn't specify /usr/sbin anywhere. Heh. I believe that my GCC installation is okay, but slightly unusual: /usr/bin/gcc is a symlink: -> /usr/app/gcc3.0.3posix/bin/gcc /usr/app/gcc -> /usr/app/gcc3.0.3posix /usr/sbin -> /usr/bin PATH=/home/vda/bin:/sbin:/usr/sbin:/bin:/usr/bin so when I run gcc it actually runs /usr/sbin/gcc. Am I weird? ;) GCC developers did not expect it and when GCC tries to internally add -iprefix to the commandline it looks for $GCC_EXEC_PREFIX in environment and, failing that, takes gcc startup path as a base. That's where /usr/sbin came into gcc commandline. This is IMHO wrong. Most other programs hardcode their installation paths as directed at configure time (still not good, you cannot move installed binaries without breaking things) or have small $PACKAGE-config script which spits out paths to the stdio (I like this!). I have 38 *-config* files in my /usr/bin so I think it is an accepted practice. When I built GCC (a while ago) I hoped it will take at least route of hardcoding paths and ./configured it this way: Configured with: ../gcc-3.0.3/configure --prefix=/usr/app/gcc-3.0.3posix --exec-prefix=/usr/app/gcc-3.0.3posix --bindir=/usr/app/gcc-3.0.3posix/bin --libdir=/usr/lib --infodir=/usr/app/gcc-3.0.3posix/info --mandir=/usr/app/gcc-3.0.3posix/man --with-slibdir=/usr/lib --with-local-prefix=/usr/local --with-gxx-include-dir=/usr/include/g++-v3 --enable-threads=posix but as it turns out this is not enough. For time being I run kernel make like this: GCC_EXEC_PREFIX=/usr/app/gcc/lib/gcc-lib/ make ... ... ... BTW, here is gcc.c source snippet which sets up -iprefix: ========================================================= /* Set up the default search paths. If there is no GCC_EXEC_PREFIX, see if we can create it from the pathname specified in argv[0]. */ #ifndef VMS /* FIXME: make_relative_prefix doesn't yet work for VMS. */ if (!gcc_exec_prefix) { gcc_exec_prefix = make_relative_prefix (argv[0], standard_bindir_prefix, standard_exec_prefix); //printf("vda: gcc_exec_prefix 2:%s\n",gcc_exec_prefix); if (gcc_exec_prefix) putenv (concat ("GCC_EXEC_PREFIX=", gcc_exec_prefix, NULL_PTR)); } #endif if (gcc_exec_prefix) { int len = strlen (gcc_exec_prefix); if (len > (int) sizeof ("/lib/gcc-lib/") - 1 && (IS_DIR_SEPARATOR (gcc_exec_prefix[len-1]))) { temp = gcc_exec_prefix + len - sizeof ("/lib/gcc-lib/") + 1; if (IS_DIR_SEPARATOR (*temp) && strncmp (temp + 1, "lib", 3) == 0 && IS_DIR_SEPARATOR (temp[4]) && strncmp (temp + 5, "gcc-lib", 7) == 0) len -= sizeof ("/lib/gcc-lib/") - 1; } set_std_prefix (gcc_exec_prefix, len); add_prefix (&exec_prefixes, gcc_exec_prefix, "GCC", PREFIX_PRIORITY_LAST, 0, NULL_PTR); add_prefix (&startfile_prefixes, gcc_exec_prefix, "GCC", PREFIX_PRIORITY_LAST, 0, NULL_PTR); } -- vda ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2002-09-30 8:05 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-09-27 12:58 Does kernel use system stdarg.h? Denis Vlasenko 2002-09-27 8:26 ` Russell King 2002-09-27 13:20 ` Denis Vlasenko 2002-09-27 9:31 ` Mikael Pettersson 2002-09-27 17:18 ` Denis Vlasenko 2002-09-27 14:05 ` Daniel Jacobowitz 2002-09-27 21:47 ` Oliver Xymoron 2002-09-28 8:15 ` Russell King 2002-09-28 9:34 ` Alan Cox 2002-09-28 10:59 ` Tomas Szepe 2002-09-28 17:26 ` Russell King 2002-09-29 1:16 ` Keith Owens 2002-09-28 15:13 ` Oliver Xymoron [not found] ` <20020927140302.B13401@flint.arm.linux.org.uk> 2002-09-30 12:58 ` Denis Vlasenko
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).