Re: [gentoo-alt] clang on Mac OS X (Was: Question before setting up sage-on-gentoo)

[Fabian Groffen]

Very nice writeup! some comments inline

On 31-01-2015 15:52:52 +0100, Michael Weiser wrote:
> Unfortunately that merge will almost certainly fail at the very last
> minute because of invalid install names in some iphone simulator runtime
> library. So either merge with FEATURE="allow_broken_install_names" or
> make an overlay with the llvm ebuilds in it and patch them with the
> patch from this bug:
>
> https://bugs.gentoo.org/show_bug.cgi?id=536716

I'll see to applying this one, looks like you fixed some bugs there.

> There is another bug however that provides somewhat preliminary/hackish
> ebuilds for libc++abi and libc++ for Darwin:
>
> https://bugs.gentoo.org/show_bug.cgi?id=474748
> https://bugs.gentoo.org/attachment.cgi?id=394024

I'll try and see if I can add these.  I'd love to get into a state where
we can bootstrap into a fully self-providing clang.

> Note how clang++ -stdlib=libc++ is now used to compile ld64 and how ld
> -v reports LTO support (unfortunately not when called via the
> binutils-config wrapper but when called directly):

I'll try to tackle this, I guess it's because we insist on adding
command line arguments even through you do nothing.

> Finally it croaked on linking cctools stuff:
>
> undef: _prune_trie
> Undefined symbols for architecture x86_64:
>   "_prune_trie", referenced from:
>       _strip_symtab in strip.private.o
> ld: symbol(s) not found for architecture x86_64
>
> Most likely the -flto was missing when compiling some file. So there's
> definitely some work to be done there.

Ok.  Recently I saw a problem like this with Apple's Clang which was
caused by the respective functions declared inline (e.g. bug).  But I
guess this is a different issue.

> 1. portage currently masks OS X 10.10 as 10.9 because
> gcc-apple-4.2.1_p5666-r2 can't currently cope with 10.10. This will
> influence clang as well. All the stuff you compile will default to
> deployment target 10.9 unless you explicitly override that using a
> command line option to clang.
>
> There is a patch in a bug that lifts that limitation:
> https://bugs.gentoo.org/show_bug.cgi?id=537826. With that in place in
> the gcc ebuild and recompiled gcc you can override

I'll apply this and lift the awkward limitation.

> 2. As far as I was able to discern, clang/llvm are configured and
> patched to use -I$EPREFIX/usr/include and -L$EPREFIX/usr/lib by default.
> And it does work. But clang silently falls back to the system
> directories if for whatever reason it does not look there or is unhappy
> with what it finds or does not find there. So check your compiles from
> time to time to see if they're really using the headers and libraries
> you expect them to use.

Hmmm, this is bad :(

> 3. I've just recently noticed that clang++ *always* uses the system's
> libstdc++ because it just doesn't look for it anywhere else. I am looking
> into this and plan to write a patch for it. Obviously that's a
> no-brainer if you use libc++ anyway.

This is even worse :(

> 4. If you would like to try cross-compiling to arm, then you're in
> totally uncharted territories. There is however a patch to the
> binutils-config ebuild that at least makes clang produce binaries at
> all: https://bugs.gentoo.org/show_bug.cgi?id=537684.

I'll add this to my todo list for today, need to patch it anyway for the
-v above.

> 5. llvm/clang silently uses the Xcode tools and SDKs to compile its
> runtime libraries. The patch from this bug forces it to use itself (the
> compiler it has just compiled and is about to install) to compile
> those runtimes: https://bugs.gentoo.org/show_bug.cgi?id=537342. This
> disables compliation of all the stuff for ios, however.

Great! another one for the todo list.

> That's almost always due to the fact that Apple has started using clang
> extensions *in the system headers* and does not test it against other
> compilers any more. So while they have basic support for disabling those
> extensions e.g. in /usr/include/os/base.h they do not use them
> consistently.
>
> Those are __has_extension and __has_feature. There are two ways to deal
> with those:
>
> 1. First check if the include of the offending heder is needed at all. I
> was able to make at least two packages work again by just removing a
> senseless include that was pulling in one of those __has_features.

I'm affraid this is a solution that works only in a very few cases.

> 2. Define them to nothing as explained here:
> http://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros

I remember doing this for some package.  I wonder if we shouldn't do
something with gcc's fixincludes to make this work for GCC by default.
I do feel gcc may be a dead-end for Mac OS X, but FSF-gcc may always be
nice to have from a development perspective.

Fabian

-- 
Fabian Groffen
Gentoo on a different level