From owner-svn-src-all@FreeBSD.ORG Wed Apr 17 06:26:17 2013 Return-Path: Delivered-To: svn-src-all@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 2C09D398; Wed, 17 Apr 2013 06:26:17 +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 F087BDCF; Wed, 17 Apr 2013 06:26:16 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r3H6QGWi067875; Wed, 17 Apr 2013 06:26:16 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id mrthxfvvujxf3k4cgie7n4y9i2; Wed, 17 Apr 2013 06:26:16 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Subject: Re: svn commit: r249484 - head/lib Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Tue, 16 Apr 2013 23:26:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <475555FA-DF6A-42FA-990D-4224ECAEAE52@FreeBSD.org> References: <201304141913.r3EJDqPI095965@svn.freebsd.org> <516D54F5.4010501@FreeBSD.org> <2A0FC59F-E043-4B4E-BABE-E16C6A1FBF5C@freebsd.org> To: Juli Mallett X-Mailer: Apple Mail (2.1283) Cc: svn-src-head@FreeBSD.org, Tijl Coosemans , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 06:26:17 -0000 On Apr 16, 2013, at 11:06 PM, Juli Mallett wrote: > On Tue, Apr 16, 2013 at 11:00 PM, Tim Kientzle = wrote: >>=20 >> On Apr 16, 2013, at 6:41 AM, Tijl Coosemans wrote: >>=20 >>> 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 >>>>=20 >>>> Log: >>>> Install a symlink >>>> /usr/lib/include =3D=3D> /usr/include >>>>=20 >>>> This fixes -print-file-name=3Dinclude in clang (and is >>>> arguably a better way to fix the same issue in GCC than >>>> the change I made in r231336). >>>>=20 >>>> MFC after: 1 week >>>>=20 >>>> Modified: >>>> head/lib/Makefile >>>>=20 >>>> 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 >>> 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? 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=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. > 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=3Dinclude to identify the directory containing the basic freestanding header files. 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. Tim