svn commit: r249484 - head/lib

[Tim Kientzle]

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>
_______________________________________________
svn-s...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all...@freebsd.org"

[Gennady Proskurin]

Here is the quote from r231336 commit message:
===
commit be984b719cbcb225dc4afaf9f52b38fb882a09d3
Author: kientzle <kientzle@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Date: Fri Feb 10 05:05:42 2012 +0000

Implement -print-file-name=include (which is undocumented
but used by some Linux boot loaders). This option prints
out the directory holding the include files needed by
a freestanding program. The default implementation of
this doesn't work on FreeBSD because of the different
include file layout. But it's easy to implement:
just return /usr/include (or the cross-compiling equivalent).
===

It turns out, that now we create useless symlink /usr/lib/include just to ease
support of "some Linux boot loaders"?

I do not have full knowledge about the issue, so excuse me if I misunderstood
something.

> svn-sr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head...@freebsd.org"

[Peter Jeremy]

On Sun, Apr 14, 2013 at 07:13:52PM +0000, Tim Kientzle wrote:
> Install a symlink
> /usr/lib/include ==> /usr/include

April 1st was several weeks ago.

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

I would disagree that this is a better solution.

On 2013-Apr-15 16:33:50 +0400, Gennady Proskurin <gpr...@mail.ru> wrote:
>Here is the quote from r231336 commit message:

> Implement -print-file-name=include (which is undocumented
> but used by some Linux boot loaders).

I don't see why base needs to grow an ugly symlink to support a couple
of ports. Surely if ports rely on an undocumented features of the
toolchain, the correct solution is to fix the ports.

--
Peter Jeremy

[Tijl Coosemans]

This breaks with -DNO_CLEAN defined, because then
${DESTDIR}/usr/lib/include/include is created.

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.

[Tim Kientzle]

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

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

[Juli Mallett]

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
>

[Tim Kientzle]

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=include 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=include to identify the directory containing
the basic freestanding header files.

The -print-file-name=include 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.

[Juli Mallett]

On Tue, Apr 16, 2013 at 11:26 PM, Tim Kientzle <kien...@freebsd.org> wrote:
>
> On Apr 16, 2013, at 11:06 PM, Juli Mallett wrote:
>> 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=include 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.

Right...

>> (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=include to identify the directory containing
> the basic freestanding header files.
>
> The -print-file-name=include 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.

I'm confused as to how it wasn't working, and am not convinced that it
shouldn't be fixed otherwise. It seems like for clang the user ought
to get /usr/include/clang/{version}, except for the problem that we
don't put some headers there that some software might expect; so maybe
we should just install copies of things like stddef.h into the
compiler-specific directory as well? I'm not sure I'm fully
understanding your needs, or what you're seeing in practice.
Certainly none of those systems have a /usr/lib/include AFAIK; this
seems like we're just not deploying our compilers configured in the
way that some software (perhaps rightly) expects.

And -print-file-name=include doesn't give you the full search path;
shouldn't it just give the compiler-specific include directory? You
really want something like:

% clang -E -Xpreprocessor -v -x c /dev/null

For C, and -x c++ for C++.

What are the headers you are expecting to find? stddef.h, stdbool.h,
stdarg.h? I think I'd rather just see those installed in the
compiler-specific dirs, and if we're not spitting those out with our
stock-built compilers, we should fix that to match behaviour on other
systems. Other systems' -print-file-name=include doesn't expose all
of /usr/include, as far as I can tell. That seem excessive and wrong
for a freestanding build.

[John Baldwin]

On Wednesday, April 17, 2013 8:05:31 am Tijl Coosemans wrote:
> 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)

I have a local patch to that that I've sent to brooks@ previously to
let it install all the intrinsic headers as I needed this for using
clang on 8.x.

--- tools/clang/lib/Headers/Makefile.orig
+++ tools/clang/lib/Headers/Makefile
@@ -13,7 +13,7 @@
# FIXME: Get version from a common place.
HeaderDir := $(PROJ_OBJ_ROOT)/$(BuildMode)/lib/clang/1.0/include

-HEADERS := $(notdir $(wildcard $(PROJ_SRC_DIR)/*.h))
+HEADERS := $(notdir $(wildcard $(PROJ_SRC_DIR)/*mm*.h
$(PROJ_SRC_DIR)/*intrin*.h $(PROJ_SRC_DIR)/altivec.h $(PROJ_SRC_DIR)/cpuid.h))

OBJHEADERS := $(addprefix $(HeaderDir)/, $(HEADERS))

And then updates to pkg-plist:

--- ports/lang/clang/pkg-plist 2013-03-14 02:43:15.953661102 -0400
+++ ports/lang/clang/pkg-plist 2013-03-04 16:35:57.632039413 -0500
@@ -390,19 +390,33 @@
lib/clang/%%PORTVERSION%%/include/__wmmintrin_aes.h
lib/clang/%%PORTVERSION%%/include/__wmmintrin_pclmul.h
lib/clang/%%PORTVERSION%%/include/ammintrin.h
+lib/clang/%%PORTVERSION%%/include/altivec.h
lib/clang/%%PORTVERSION%%/include/arm_neon.h
+lib/clang/%%PORTVERSION%%/include/avx2intrin.h
+lib/clang/%%PORTVERSION%%/include/avxintrin.h
+lib/clang/%%PORTVERSION%%/include/bmi2intrin.h
+lib/clang/%%PORTVERSION%%/include/bmiintrin.h
+lib/clang/%%PORTVERSION%%/include/cpuid.h
lib/clang/%%PORTVERSION%%/include/emmintrin.h
+lib/clang/%%PORTVERSION%%/include/f16cintrin.h
+lib/clang/%%PORTVERSION%%/include/fmaintrin.h
+lib/clang/%%PORTVERSION%%/include/fma4intrin.h
lib/clang/%%PORTVERSION%%/include/immintrin.h
+lib/clang/%%PORTVERSION%%/include/lzcntintrin.h
lib/clang/%%PORTVERSION%%/include/mm3dnow.h
lib/clang/%%PORTVERSION%%/include/mm_malloc.h
lib/clang/%%PORTVERSION%%/include/mmintrin.h
lib/clang/%%PORTVERSION%%/include/module.map
lib/clang/%%PORTVERSION%%/include/nmmintrin.h
lib/clang/%%PORTVERSION%%/include/pmmintrin.h
+lib/clang/%%PORTVERSION%%/include/popcntintrin.h
+lib/clang/%%PORTVERSION%%/include/rtmintrin.h
lib/clang/%%PORTVERSION%%/include/smmintrin.h
lib/clang/%%PORTVERSION%%/include/tmmintrin.h
lib/clang/%%PORTVERSION%%/include/wmmintrin.h
+lib/clang/%%PORTVERSION%%/include/x86intrin.h
lib/clang/%%PORTVERSION%%/include/xmmintrin.h
+lib/clang/%%PORTVERSION%%/include/xopintrin.h
lib/libclang.a
lib/libclang.so
lib/libclangARCMigrate.a

--
John Baldwin

[Tijl Coosemans]

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

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?
>
> 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=include 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.)
>
> 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=include 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=include?

> The -print-file-name=include 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
...
#endif

[Tim Kientzle]

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.

That's what the U-Boot sources do, yes.

>> The -print-file-name=include 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).

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

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

[Dimitry Andric]

On Apr 17, 2013, at 17:58, Tim Kientzle <kien...@freebsd.org> wrote:
> On Apr 17, 2013, at 5:05 AM, Tijl Coosemans wrote:

...

>> So you compile with -ffreestanding -nostdinc?
>> And then add the include path returned by -print-file-name=include?
>
> That's what the U-Boot sources do, yes.

Why would U-Boot want to build for a freestanding environment, then
include standard headers? Isn't that a bit backwards? :-)

>>> The -print-file-name=include 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).
>
> I would certainly like to see that. I presumed that there
> was some reason this wasn't done in the initial import.

Probably because headers belong under /usr/include, not in a library
directory? I do not really agree with upstream's decision to place
their internal headers in that location. Third-party software depending
on their exact location is just a little braindead IMHO.

In any case, the layout has been like this since the initial clangbsd
import, and I never saw any reason to change it. Maybe Ed can tell a
bit more, since he seems to have done the initial infrastructure setup.

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

Indeed, some of clang's internal headers currently conflict with our
own, due to several declarations and definitions, and therefore we do
not install them at this time. Again, this could be changed, but not
without good reason. One specific third-party project is not enough, I
think. (Especially since our kernel is also freestanding, and does not
depend on these internals.)

[Tijl Coosemans]

On 2013-04-17 19:33, Dimitry Andric wrote:
> On Apr 17, 2013, at 17:58, Tim Kientzle <kien...@freebsd.org> wrote:
>> On Apr 17, 2013, at 5:05 AM, Tijl Coosemans wrote:
>>> So you compile with -ffreestanding -nostdinc?
>>> And then add the include path returned by -print-file-name=include?
>>
>> That's what the U-Boot sources do, yes.
>
> Why would U-Boot want to build for a freestanding environment, then
> include standard headers? Isn't that a bit backwards? :-)

There's a list of headers in the standard that freestanding
programs are allowed to include. If they drop -nostdinc it
should build on FreeBSD. I suppose they use it to prevent
accidental use of non-freestanding stuff in the headers.

>>>> The -print-file-name=include 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).
>>
>> I would certainly like to see that. I presumed that there
>> was some reason this wasn't done in the initial import.
>
> Probably because headers belong under /usr/include, not in a library
> directory? I do not really agree with upstream's decision to place
> their internal headers in that location. Third-party software depending
> on their exact location is just a little braindead IMHO.

It doesn't really depend on the exact location. It relies on
-print-file-name=include to return the location which our clang
doesn't.

I agree that headers don't belong under lib/, but that's something
to discuss upstream. FreeBSD doing little things like this
differently than everybody else just makes it harder to use imho.

[Tim Kientzle]

On Apr 17, 2013, at 10:33 AM, Dimitry Andric wrote:

> In any case, the layout has been like this since the initial clangbsd
> import, and I never saw any reason to change it. Maybe Ed can tell a
> bit more, since he seems to have done the initial infrastructure setup.

FreeBSD/ARM just switched from GCC to Clang, which is
why this just got noticed. U-Boot is used quite heavily for
FreeBSD/ARM (and MIPS and PowerPC as well, I believe).

Here are the options I see for getting
cc -print-file-name=include
to work again:

* Hack clang to handle -print-file-name=include specially.
I did this for GCC already, but I'm not thrilled about it.

* Configure clang differently so that this option works.

* Symlink /usr/include to appear somewhere that clang expects.

* Rearrange our directory layout slightly to match clang's expectations.

Tim

[Dimitry Andric]

On Apr 19, 2013, at 06:50, Tim Kientzle <kien...@freebsd.org> wrote:
> On Apr 17, 2013, at 10:33 AM, Dimitry Andric wrote:
>
>> In any case, the layout has been like this since the initial clangbsd
>> import, and I never saw any reason to change it. Maybe Ed can tell a
>> bit more, since he seems to have done the initial infrastructure setup.
>
> FreeBSD/ARM just switched from GCC to Clang, which is
> why this just got noticed. U-Boot is used quite heavily for
> FreeBSD/ARM (and MIPS and PowerPC as well, I believe).
>
> Here are the options I see for getting
> cc -print-file-name=include
> to work again:
>
> * Hack clang to handle -print-file-name=include specially.
> I did this for GCC already, but I'm not thrilled about it.
>
> * Configure clang differently so that this option works.
>
> * Symlink /usr/include to appear somewhere that clang expects.
>
> * Rearrange our directory layout slightly to match clang's expectations.

You seem to have left out the most obvious one:

* Fixing U-Boot's configuration script(s) so they don't depend on undocumented compiler options.

I don't understand why we would want to go through all this trouble, just for telling U-Boot where a bunch of headers are located? What happened to configure scripts with options, they did not disappear overnight, I hope?