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

[Michael Weiser]

Hi Fabian,

On Sat, Jan 31, 2015 at 04:57:55PM +0100, Fabian Groffen wrote:

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

I've just updated those with my most recent ones. They aren't all that
hackish anymore and tested quite a bit. As always, backporting to older
OS Xes revealed some misconceptions and dependencies. But since they
started life somewhere completely different and were hacked by different
people and finally put on a strict diet by me (dropped multilib stuff
and made them plain, straightforward ebuilds), they might not confirm to
some Gentoo policies. So please feel free to subject them to some
scrutiny.

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

Come to think of it, I'm pretty sure, it's at least partly Apple
braindeadness at work. The code for option -v in ld64 actually reads:

fprintf(stderr, "configured to support archs: %s\n", ALL_SUPPORTED_ARCHS);
 // if only -v specified, exit cleanly
 if ( argc == 2 ) {
        const char* ltoVers = lto::version();
        if ( ltoVers != NULL )
                fprintf(stderr, "LTO support using: %s\n", ltoVers);
        exit(0);
}

I guess, once upon a time, they wanted to exit immediately if called
with only -v and then someone stuck the LTO support message into the
wrong code block. So now they only inform about LTO support if *only* -v
was given and they're gonna exit. Worse: Some braindead script somewhere
*will* expect it to behave that way. So basically the only thing to be
done is to make the wrapper not add any additional options if it itself
was called with only -v.

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

Mhmm, it's always the same: Up until this writeup, LTO wasn't really on
my project list. Now I've got to know. I'll give it some digging. :)

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

This might need to be done in quite some steps: Can you have a
dependency in a profile on a certain package version being installed
*before* the new profile is used? Otherwise we'd have to wait until
everyone has updated their gcc-apple before setting
MACOSX_DEPLOYMENT_TARGET to 10.10.

Also: I found that ld64 from binutils-apple-4.3 doesn't understand 10.10
as a deployment target either. I've backported the fix from 6.1 and have
an updated ebuild. A new bug for that should pop up in a couple of
hours, I think. But that would still become 4.3-r1, I guess, so that we'd
need to require people to update their binutils-apple as well before
changing the deployment target in the profile.

On a positive note: I've had the ld wrapper that doesn't add
-macos-version-min to the linker command line in use for some time and
haven't had any fallout yet with or without deployment target being set
to 10.10.
 
> > 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 :(

Nah, not all that bad: The last time that happened for me was when I
worked on bootstrapping libc++ and actually was missing the headers from
my prefix. All I wanted to point out was that clang in prefix isn't as
well tested as gcc and binutils where we've even got special wrappers in
place to bend them to our will. So people should be aware to look out
for this kind of thing wheras with gcc they might just expect that to
work.

> > 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 :(

Yep, this is bad. What's worse: Clang has a GCCInstallationDetector. And
that has a path for Gentoo in
clang-3.5-gentoo-runtime-gcc-detection-v3.patch. But that's only used on
Linux. :-(

The equivalent Darwin function is really tiny and just concerned with
what library name to use but not which path to look in. They try
/usr/lib and otherwise just put -lstdc++ to the linker and let it
search. But even with the ld wrapper and it's search paths we'd need it
to emit -lstdc++.6 or add another directory deep inside
${EPREFIX}/usr/lib to the wrapper's forced search paths - with unknown
consequences for all packages.

So I've downloaded 600MB of doxygen clang documentation to try to get a
handle on whether I can use that GCCInstallationDetector and the Gentoo
patch on OS X as well or if I have to duplicate the logic for Darwin.

On the other hand we might get away with patching clang so that it puts
-l<right name> to the linker and depend on the ld wrapper to sort it
out.

A proper Gentoo-compatible GCCInstallationDetector for Darwin would be
nice though, wouldn't it?

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

I'm uncertain what the correct route is to go here: Compiling everything
with itself is the right way to go on principle because it avoids
weird fallout later on. But throwing away all the iOS stuff just for
that seems a bit excessive to me. What's your sentiment on that?

There might be a compromise but that would mean replacing all the xc-run
calls in the Makefiles so that the SDKs can stay enabled and remain in
use but with our freshly built compiler. I think that would make for
quite a large patch.

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

Yep, but it's the preferable route in the long run. It worked nicely
with cctools/ld64 because those suffer from serious include bitrot.

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

gcc-apple for libstdc++. In fact my new 10.10 patch still has that in it.

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

The following mail thread and corresponding bug have some stuff for
fixincludes and __has_feature for FSF GCC 4.9 in it:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01402.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407

But only the deployment target macro stuff seems to have made it into
trunk (what I backported to gcc-apple). The bug does however have loads
of links to MacPorts that I hadn't spotted before where this fixincludes
stuff seems to be in active use.
-- 
bye,
Micha