Date: Mon, 30 Jan 2012 21:12:33 -0800 From: Tim Kientzle <tim@kientzle.com> To: Jeroen Hofstee <freebsd_arm@myspectrum.nl> Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD and BeagleBone Message-ID: <F361D76E-6718-4A97-A35C-75B9A27B4600@kientzle.com> In-Reply-To: <4F271258.2060203@myspectrum.nl> References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> <CABt%2Bj0mB4w==h_SQ4YyDM24_wGOjcdZDK9T1N3DqjSkap0VkQw@mail.gmail.com> <E8A24EBE-967D-44F8-A884-3207B3C6F0FE@bsdimp.com> <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> <CAGW5k5ahyaTest3L0NTe1t%2B%2BYBgpLMkWZNpp=GRyz%2Bg=nMcZLg@mail.gmail.com> <7E53112E-DE29-4145-B597-D39AA77252C5@kientzle.com> <E1RoGMT-000DkR-6a@groundzero.grondar.org> <AEF07CD1-6794-4F04-AF9C-938423FE919B@kientzle.com> <4F25D8F9.8040108@myspectrum.nl> <F72663A5-E7BA-43A3-9E34-F7EF7512775E@kientzle.com> <4F271258.2060203@myspectrum.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D<library> form.
>>=20
>> Can you point me to docs for this option?
>>=20
>> [jeroen@laptop_freebsd ~]$ gcc34 -print-file-name=3Dinclude
> 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=3Dinclude
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=3Dinclude
/usr/arm-freebsd/usr/lib/include
The base system could do the same by creating
a symlink /usr/lib/include =3D=3D> /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=3Dinclude as a special option within
gcc.c (separate from -print-file-name=3D<library>).
Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F361D76E-6718-4A97-A35C-75B9A27B4600>