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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
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.
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
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
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.."
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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)
> > > > -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.
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.."
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
"I know toolchain people. They _love_ to change things."
On Sat, 28 Sep 2002 18:26:43 +0100,
Russell King <[email protected]> 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 ...
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