Date: Wed, 17 Apr 2013 08:58:36 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: Tijl Coosemans <tijl@freebsd.org> Cc: src-committers@freebsd.org, Juli Mallett <jmallett@freebsd.org>, svn-src-all@freebsd.org, Dimitry Andric <dim@freebsd.org>, Brooks Davis <brooks@freebsd.org>, svn-src-head@freebsd.org Subject: Re: svn commit: r249484 - head/lib Message-ID: <BE32E940-D519-4B0B-B33F-8A8F33388EA9@freebsd.org> In-Reply-To: <516E900B.9090300@FreeBSD.org> References: <201304141913.r3EJDqPI095965@svn.freebsd.org> <516D54F5.4010501@FreeBSD.org> <2A0FC59F-E043-4B4E-BABE-E16C6A1FBF5C@freebsd.org> <CACVs6=9QA_wiittSR2HGcOFaDj4VASgLHOimEGWyEcSt8UdBjA@mail.gmail.com> <475555FA-DF6A-42FA-990D-4224ECAEAE52@FreeBSD.org> <516E900B.9090300@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_3EE0F6AD-4CE8-4E89-BD09-01FEB7BC606B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
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
>>>>>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>>>>>> --- 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=3D libusbhid
>>>>>> _libusb=3D libusb
>>>>>> .endif
>>>>>>=20
>>>>>> +afterinstall:
>>>>>> + ln -fs ../include ${DESTDIR}/usr/lib/include
>>>>>> +
>>>>>> .include <bsd.subdir.mk>
>>>>>=20
>>>>> This breaks with -DNO_CLEAN defined, because then
>>>>> ${DESTDIR}/usr/lib/include/include is created.
>>>>=20
>>>> That's a good point. Would this work better?
>>>>=20
>>>> afterinstall:
>>>> if [ ! -e $(DESTDIR)/usr/lib/include ]; then
>>>> ln -fs ../include $(DESTDIR)/usr/lib/include
>>>> fi
>=20
> 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
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.)
>>>=20
>>> If you're doing a freestanding compile...shouldn't you also be
>>> specifying both include and library paths explicitly?
>>=20
>> 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.
>>=20
>> Both gcc and clang support a -print-file-name=3Dinclude 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.
>>=20
>>> (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.)
>>=20
>> 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=3Dinclude to identify the directory containing
>> the basic freestanding header files.
>=20
> So you compile with -ffreestanding -nostdinc?
> And then add the include path returned by -print-file-name=3Dinclude?
That's what the U-Boot sources do, yes.
>> The -print-file-name=3Dinclude 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.
>=20
> "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".
>=20
> 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.
>=20
> 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:
>=20
> #if __STDC_HOSTED__ && \
> defined(__has_include_next) && __has_include_next(<stdint.h>)
> # include_next <stdint.h>
> #else
> ...
> #endif
>=20
> 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
--Apple-Mail=_3EE0F6AD-4CE8-4E89-BD09-01FEB7BC606B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
iQEcBAEBAgAGBQJRbsatAAoJEGMNyGo0rfFBIecH/izjnxPHMXmS6SXkC3hTU4Aq
2rLkGOZY5WvraF/VIiGG/hqamQ7RR+YAqzAIyhcnKFeXMU/U4zd7ac1UbbdGZCNV
su8pLzUOtL80iu9dCBtZMhuqJ+/ztr/IL8InrDONjdh1rm7v78/ic0F+NIhsI+/H
VUR5udRcKc5C/8niiYQjp/l4gNQCNFPjBwDMc9HCfq7LUVnPBq7Gc+K91EJTZSVY
eMBAk8gaFAf6fb4oKOQJsTYmVenBqI9WL9KKsTcafU1WeZ9deAnkjxSZlKGLnF/Y
0EPV6ktP0AyHj9PpD/Dbkfi+mvDU/5ofD9csFpRFFcHm4siBhoTw+FOyySfEVY4=
=DJkS
-----END PGP SIGNATURE-----
--Apple-Mail=_3EE0F6AD-4CE8-4E89-BD09-01FEB7BC606B--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BE32E940-D519-4B0B-B33F-8A8F33388EA9>