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

[Fabian Groffen]

On 31-01-2015 19:25:43 +0100, Michael Weiser wrote:
> > > 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.

OK!

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

This should be doable.  Why not, eh? :)

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

I disagree.  A crude hack was put in place to make 10.10 support sort of
going.  We can make all necessary changes to get it bootstrapping,
although they may feel (and will be) disruptive.

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

Yes :)

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

I prefer to have a functional toolchain first.  Developement for iOS is
much better done with Apple's official support tool: Xcode.  Honestly,
they'll know best how/what to do it.

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

Yes, but IMO we can delay that.

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

Oh, that's nice.  Maybe we can ste^Wborrow that :)


-- 
Fabian Groffen
Gentoo on a different level