svn commit: r249484 - head/lib

[Tim Kientzle]

On Apr 16, 2013, at 11:06 PM, Juli Mallett wrote:

> On Tue, Apr 16, 2013 at 11:00 PM, Tim Kientzle <kientzle at freebsd.org> wrote:
>> 
>> On Apr 16, 2013, at 6:41 AM, Tijl Coosemans wrote:
>> 
>>> On 2013-04-14 21:13, Tim Kientzle wrote:
>>>> Author: kientzle
>>>> Date: Sun Apr 14 19:13:51 2013
>>>> New Revision: 249484
>>>> URL: http://svnweb.freebsd.org/changeset/base/249484
>>>> 
>>>> Log:
>>>> Install a symlink
>>>>   /usr/lib/include ==> /usr/include
>>>> 
>>>> This fixes -print-file-name=include in clang (and is
>>>> arguably a better way to fix the same issue in GCC than
>>>> the change I made in r231336).
>>>> 
>>>> MFC after:  1 week
>>>> 
>>>> Modified:
>>>> head/lib/Makefile
>>>> 
>>>> Modified: head/lib/Makefile
>>>> ==============================================================================
>>>> --- head/lib/Makefile        Sun Apr 14 18:36:30 2013        (r249483)
>>>> +++ head/lib/Makefile        Sun Apr 14 19:13:51 2013        (r249484)
>>>> @@ -252,4 +252,7 @@ _libusbhid=      libusbhid
>>>> _libusb=     libusb
>>>> .endif
>>>> 
>>>> +afterinstall:
>>>> +    ln -fs ../include ${DESTDIR}/usr/lib/include
>>>> +
>>>> .include <bsd.subdir.mk>
>>> 
>>> This breaks with -DNO_CLEAN defined, because then
>>> ${DESTDIR}/usr/lib/include/include is created.
>> 
>> That's a good point.  Would this work better?
>> 
>> afterinstall:
>>     if [ ! -e $(DESTDIR)/usr/lib/include ]; then
>>        ln -fs ../include $(DESTDIR)/usr/lib/include
>>     fi
>> 
>>> I'm not that fond of this patch by the way, but I don't fully
>>> understand the problem it's trying to solve so I won't object.
>>> It just looks too much like a hack to me
>> 
>> It's a subtle issue and I'm not surprised that it raised some
>> eyebrows.  I spent a long time looking for a better solution.
>> 
>> In short, both GCC and Clang make some assumptions
>> about the layout of headers used for freestanding compiles.
>> (My earlier commit said these assumptions were "undocumented",
>> but that's not quite true, they're just rather obscure.)
> 
> If you're doing a freestanding compile...shouldn't you also be
> specifying both include and library paths explicitly?

Yes, of course.  But the correct directories to use vary somewhat
across platforms, so we would like to have some reasonably
portable way to find the right directory to use for building on
a particular system.

Both gcc and clang support a -print-file-name=include option which
is supposed to print out the directory containing headers used
for freestanding compiles.  You can then take that path and
use it as the explicit include directory path for freestanding builds.

>  I just feel more confused by this explanation.  Why not just specify
> -I/usr/include?


That would be FreeBSD-specific.  Not everyone lumps all
header files together like we do.

>  (Or even better, if you're doing a freestanding
> compile, but want the default include paths, get the compiler to dump
> the default include paths and process that.)

That's precisely what this is for.  I've been working with U-Boot
sources which compile on many systems and use
-print-file-name=include to identify the directory containing
the basic freestanding header files.

The -print-file-name=include option works on Linux, works
on MacOS, and --- with this one symlink --- can work on
FreeBSD as well.  I've been using it to cross-build U-Boot
using the FreeBSD xdev toolchain with both GCC and Clang.

Tim