From owner-svn-src-head@FreeBSD.ORG Wed Apr 17 15:58:39 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D2B3809; Wed, 17 Apr 2013 15:58:39 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id D8163214; Wed, 17 Apr 2013 15:58:38 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r3HFwbbu070858; Wed, 17 Apr 2013 15:58:37 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id iiv5sbx8nfhcmmcp3vrgpt38me; Wed, 17 Apr 2013 15:58:37 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: svn commit: r249484 - head/lib Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_3EE0F6AD-4CE8-4E89-BD09-01FEB7BC606B"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Tim Kientzle In-Reply-To: <516E900B.9090300@FreeBSD.org> Date: Wed, 17 Apr 2013 08:58:36 -0700 Message-Id: References: <201304141913.r3EJDqPI095965@svn.freebsd.org> <516D54F5.4010501@FreeBSD.org> <2A0FC59F-E043-4B4E-BABE-E16C6A1FBF5C@freebsd.org> <475555FA-DF6A-42FA-990D-4224ECAEAE52@FreeBSD.org> <516E900B.9090300@FreeBSD.org> To: Tijl Coosemans X-Mailer: Apple Mail (2.1283) Cc: src-committers@freebsd.org, Juli Mallett , svn-src-all@freebsd.org, Dimitry Andric , Brooks Davis , svn-src-head@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 15:58:39 -0000 --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 >>>>>=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 - /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() > # include_next > #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--