On Apr 17, 2013, at 5:05 AM, Tijl Coosemans wrote:
> On 2013-04-17 08:26, Tim Kientzle wrote:
>> On Apr 16, 2013, at 11:06 PM, Juli Mallett wrote:
>>> On Tue, Apr 16, 2013 at 11:00 PM, Tim Kientzle wrote:
>>>> On Apr 16, 2013, at 6:41 AM, Tijl Coosemans wrote:
>>>>> On 2013-04-14 21:13, Tim Kientzle wrote:
>>>>>> 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
>
> Maybe just: ln -fs ../include $(DESTDIR)/usr/lib/Ah, yes. That is the obvious answer. I'll change it to that for now. I'm happy to remove it once we have a better answer in place. >>>>> 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. >> >>> (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. > > So you compile with -ffreestanding -nostdinc? > And then add the include path returned by -print-file-name=include? That's what the U-Boot sources do, yes. >> 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. > > "clang -E -v - </dev/null" shows it passes "-resource-dir > /usr/bin/../lib/clang/3.3" to cc1 stage which then complains about > nonexistent directory "/usr/bin/../lib/clang/3.3/include". > > So how about moving /usr/include/clang/3.3 to > /usr/lib/clang/3.3/include? That seems to be the location clang > expects and what lang/clang port uses (in /usr/local). I would certainly like to see that. I presumed that there was some reason this wasn't done in the initial import. > The path from -resource-dir is also searched by -print-file-name. > > All headers from contrib/llvm/tools/clang/lib/Headers would have > to be installed there to have a complete freestanding environment, > but some of those headers would have to be patched to use the base > system header in the hosted case like the stdint.h header does: > > #if __STDC_HOSTED__ && \ > defined(__has_include_next) && __has_include_next(<stdint.h>) > # include_next <stdint.h> > #else > ... > #endif > > In the lang/clang port files/patch-tools_clang_lib_Headers_Makefile > should be removed I think. It prevents too many useful headers from > being installed (e.g. avxintrin.h) That would be great! I can certainly help with some of this but my time is a little tight. While we're talking about freestanding brokenness, is anyone interested in fixing the fact that FreeBSD/ARM requires freestanding programs to be linked against libc? Tim
signature.asc
Description: Message signed with OpenPGP using GPGMail
