Does kernel use system stdarg.h?

Does kernel use system stdarg.h?

[Denis Vlasenko]

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

Re: Does kernel use system stdarg.h?

[Russell King]

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

Re: Does kernel use system stdarg.h?

[Denis Vlasenko]

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 

Re: Does kernel use system stdarg.h?

[Mikael Pettersson]

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.

Re: Does kernel use system stdarg.h?

[Denis Vlasenko]

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

Re: Does kernel use system stdarg.h?

[Daniel Jacobowitz]

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

Re: Does kernel use system stdarg.h?

[Oliver Xymoron]

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.." 

Re: Does kernel use system stdarg.h?

[Russell King]

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

Re: Does kernel use system stdarg.h?

[Alan Cox]

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)

Re: Does kernel use system stdarg.h?

[Tomas Szepe]

> > > > -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.

Re: Does kernel use system stdarg.h?

[Russell King]

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."

Re: Does kernel use system stdarg.h?

[Keith Owens]

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 ...

Re: Does kernel use system stdarg.h?

[Oliver Xymoron]

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.." 

Re: Does kernel use system stdarg.h?

[Denis Vlasenko]

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