tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Small compiler issues


On Fri, Jun 25, 2010 at 5:16 PM, matthew green <> 
>> 1)
>> The "-print-file-name" option does not seem to be functional. This
>> happen only with the "system" compiler. The "tools" compiler is
>> working as expected:
>> "System" compiler:
>> % gcc -print-file-name=include
>> include
>> "Tools" compiler:
>> % /tools/tools-i386/bin/i486--netbsdelf-gcc -print-file-name=include
>> /tools/tools-i386/lib/gcc/i486--netbsdelf/4.1.3/include
> while this is clearly different, i'm not sure it is a bug.  the
> -print-file-name is used to find libraries.  since there's no
> "include" in any of the default library paths, the result is what
> you see -- what you asked for.  eg, it works fine for libs:
> % gcc -print-file-name=libgcc.a
> /usr/lib/libgcc.a
> what is your use-case for this?
Actually, it is a silly dirty-hack consisting to build a linux kernel
with "our" standard system compiler[0]. The Makefile is using
-print-file-name=include to get gcc's own include directory,
overriding the system path with -isystem. The build itself work fine
at the exception of -D__linux__ to be added and this nits. So for now
I'm using the "tool" compiler.

To some other extend, `-print-file-name=plugin' has to be used with
gcc 4.5.x to get the plugin's headers. However this problem does not
yet occur to us. But still, I'm not sure if we ever have gcc 4.5.x
that we will want to have /usr/lib/plugin/include/... .

 - Arnaud

[0]: yes, I'm lazy. At the time I did that, I was unable to use a
linux toolchain as I had a silly bug (which should have been fixed) in
the compat code. So I gave it a try and it mostly worked out of box :)

Home | Main Index | Thread Index | Old Index