Re: Small compiler issues

[Arnaud Lacombe <lacombar%gmail.com@localhost>]

Hi,

On Fri, Jun 25, 2010 at 5:16 PM, matthew green <mrg%eterna.com.au@localhost> 
wrote:
>
>> 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 :)