Date: Tue, 16 Apr 2013 23:06:34 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: Tim Kientzle <kientzle@freebsd.org> Cc: svn-src-head@freebsd.org, Tijl Coosemans <tijl@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r249484 - head/lib Message-ID: <CACVs6=9QA_wiittSR2HGcOFaDj4VASgLHOimEGWyEcSt8UdBjA@mail.gmail.com> In-Reply-To: <2A0FC59F-E043-4B4E-BABE-E16C6A1FBF5C@freebsd.org> References: <201304141913.r3EJDqPI095965@svn.freebsd.org> <516D54F5.4010501@FreeBSD.org> <2A0FC59F-E043-4B4E-BABE-E16C6A1FBF5C@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 16, 2013 at 11:00 PM, Tim Kientzle <kientzle@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? I just feel more confused by this explanation. Why not just specify -I/usr/include? (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.) /usr/lib/include is just badly and plainly wrong unless it's absolutely, absolutely necessary. > This symlink is the simplest way I've found to reconcile those > assumptions with the FreeBSD directory layout. I'm happy to > consider alternatives. > > Tim >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=9QA_wiittSR2HGcOFaDj4VASgLHOimEGWyEcSt8UdBjA>