FreeBSD and BeagleBone

[Tim Kientzle]

On Jan 30, 2012, at 1:57 PM, Jeroen Hofstee wrote:

> On 01/30/12 03:35, Tim Kientzle wrote:
>> I might be able to come up with a workaround if I knew
>> exactly what this option did.  The most recent
>> docs on gcc.gnu.org (for GCC 4.6.2) only mention
>> the -print-file-name=<library>  form.
>> 
>> Can you point me to docs for this option?
>> 
>> [jeroen at laptop_freebsd ~]$ gcc34 -print-file-name=include
> Hi Tim, I can't. I took a pragmatic approach, looked what the eldk compiler did
> and where it differed. Googled for it, and found some print-file-name related
> bugs fixes and simple _assumed_ those where not included in the FreeBSD gcc,
> and the cause of the problem.

I traced through some of the code in gcc.c and
managed to puzzle this out.

I think this is a succinct definition of that option:

-print-file-name=include
    Prints the name of the directory containing stdarg.h
    and other basic ISO C header files.

The current gcc.c implementation works on Linux
because the directory in question is called 'include' and
resides under one of the standard 'lib' directories.  So it can
be found via a search of the library paths.

Of course, FreeBSD consolidates these headers with
the rest of the system headers under /usr/include, which
is not a subdirectory of any library path, so isn't
found by the stock gcc.c implementation.

That explains why the following symlink workaround works
(which is the same one you found):

$ sudo ln -s /usr/arm-freebsd/usr/include /usr/arm-freebsd/usr/lib/include
$ arm-freebsd-gcc -print-file-name=include
/usr/arm-freebsd/usr/lib/include

The base system could do the same by creating
a symlink /usr/lib/include ==> /usr/include, but I'm not
convinced the FreeBSD folks would go for that.  ;-)

Long-term, I think the real answer is to implement
-print-file-name=include as a special option within
gcc.c (separate from -print-file-name=<library>).

Tim