Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Apr 2013 14:05:31 +0200
From:      Tijl Coosemans <tijl@FreeBSD.org>
To:        Tim Kientzle <kientzle@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:  <516E900B.9090300@FreeBSD.org>
In-Reply-To: <475555FA-DF6A-42FA-990D-4224ECAEAE52@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>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2MJRKOHIWUDIFGFPCMTRT
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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        (r2494=
83)
>>>>> +++ head/lib/Makefile        Sun Apr 14 19:13:51 2013        (r2494=
84)
>>>>> @@ -252,4 +252,7 @@ _libusbhid=3D      libusbhid
>>>>> _libusb=3D     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/

>>>> 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?
>=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.
>
>>  (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.

So you compile with -ffreestanding -nostdinc?
And then add the include path returned by -print-file-name=3Dinclude?

> 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.

"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).

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
=2E..
#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)


------enig2MJRKOHIWUDIFGFPCMTRT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iF4EAREIAAYFAlFukA8ACgkQfoCS2CCgtivnDwEAhwB1rOo6vWCU19JorragUE4f
l6JggnJGtDZWi5TAccoA/ioO41XLsdwEHl/E5gCrSFA26rrqWjXAcwpkkjbGjtdz
=L+uL
-----END PGP SIGNATURE-----

------enig2MJRKOHIWUDIFGFPCMTRT--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?516E900B.9090300>