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

[Michael Weiser]

Hi all,

On Fri, Jan 30, 2015 at 09:04:40AM +0900, heroxbd@g.o wrote:

> There are efforts on-going to make modern toolchain on gentoo-prefix @
> darwin.

> I am sure guys from gentoo-alt (in the Cc) will show you the most recent
> progress.

I've been meaning to do a bit of a write-up on the state of things and
the process I'm using currently. This seems like a good opportunity.

Disclaimer: This is only my own personal understanding of things. I'm
not a Gentoo or prefix developer. I might have misinterpreted something
or all of it. I'm sure, the experts will correct me if I'm wrong
somewhere. So read all of the following with healthy scepticism. ;)

Compiling llvm/clang with prefix on OS X works almost out of the box
now: You just bootstrap your prefix normally. That should since a few
days ago yield a prefix with binutils-apple-6.1 and
gcc-apple-4.2.1_p5666-r2. This prefix is able to

# USE="clang" emerge =sys-devel/llvm-3.4.2

Note the version: llvm-3.5.0 and later require C++11 support to compile
which gcc-apple doesn't have. But llvm-3.4.2 can be compiled using
gcc-apple and can itself compile and link stuff with the new
binutils-apple.

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

This gives you an llvm/clang 3.4.2 that uses the the system's (see
below) libstdc++ by default. You should be able to compile stuff with
"-stdlib=libc++" using the system's libc++ headers and libraries thus
gaining C++11 support. This is only necessary if you want to compile
programs that require C++11 support such as llvm-3.5.1.

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

With those in your overlay you can do an

# emerge libcxx-apple

and will get libc++-3.5.1 and its headers in your prefix.

However you opt, you can now try a

CC=clang CXX="clang++ -stdlib=libc++" USE="clang" emerge llvm

(with those updated ebuilds from your overlay) and should get a fully
working llvm/clang-3.5.1. I have installed an environment configuration
in my $EPREFIX/etc/portage/env that automates that:

michael@osx1010:~ # cat $EPREFIX/etc/portage/env/clanglibc++ 
CC=clang
CXX="clang++ -stdlib=libc++"
michael@osx1010:~ # cat $EPREFIX/etc/portage/package.env
sys-devel/llvm clanglibc++
sys-devel/binutils-apple clanglibc++

A good final test is to recompile binutils-apple with libc++ and LTO
support:

USE="libcxx lto" emerge -1 binutils-apple

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

# $EPREFIX/usr/x86_64-apple-darwin14/binutils-bin/6.1/ld -v
@(#)PROGRAM:ld  PROJECT:ld64-241.9 (Gentoo binutils-apple-6.1)
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m arm64
LTO support using: LLVM version 3.5.1

So now you should even be able to compile stuff using clang -flto.
Beware: I've tried that and it works for an int main(void) {}. I have
just tried it on binutils-apple and it produced an ld64 that can be run
and outputs its version information. But compilation spewed "LTO
remarks" like nothing I've ever seen:

ld: LTO remark: <unknown>:0:0: loop not vectorized: loop control flow is not understood by vectorizer
ld: LTO remark: <unknown>:0:0: loop not vectorized: vectorization was not specified
ld: LTO remark: <unknown>:0:0: vectorization is not beneficial and is not explicitly forced
ld: LTO remark: <unknown>:0:0: loop not vectorized: loop control flow is not understood by vectorizer
ld: LTO remark: <unknown>:0:0: loop not vectorized: vectorization was not specified
ld: LTO remark: <unknown>:0:0: loop not vectorized: loop control flow is not understood by vectorizer
ld: LTO remark: <unknown>:0:0: loop not vectorized: vectorization was not specified
ld: LTO remark: <unknown>:0:0: loop not vectorized: loop control flow is not understood by vectorizer
ld: LTO remark: <unknown>:0:0: loop not vectorized: vectorization was not specified

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.

Finally there are some quirks you should be aware of when trying all of
this:

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

export MACOSX_DEPLOYMENT_TARGET=10.9

from $PORTDIR/profiles/prefix/darwin/macos/10.10/profile.bashrc (the one
marked with "this is not a typo") to 10.10 and get the expected
behaviour on 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.

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.

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.

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.

> > other package that asks for a more recent gcc. Right now I get a
> > working basic system but almost all "higher" application fail to build
> > one or the other way.

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.

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

Good luck!

Michael

> JC D <mail2jcdx@×××××.de> writes:

> > here are the first results. It did not work so far because I found my
> > gcc-4.7.3 on gentoo_prefix (Mac OS 10.10) is broken. emerge gcc works
> > and installs but if I try to compile a simple hello.cpp I get a
> > segmentation fault 11. I am using the new binutils-apple-6.1. So far
> > it seems that I can not get a newer gcc and thus also no llvm or any
> > other package that asks for a more recent gcc. Right now I get a
> > working basic system but almost all "higher" application fail to build
> > one or the other way.
> >
> > Now I try to get llvm/clang working. For the compilation I am going to
> > use the native llvm-gcc and llvm-g++ from Mac.
> > I set up a package.env for llvm with:
> > sys-devel/llvm llvm.conf
> >
> > llvm.conf contains:
> > CC=/usr/bin/llvm-gcc
> > CXX=/usr/bin/llvm-g++
> >
> > The compilation works but there is an error when writing the llvm
> > files to the right path. Here are emerge --info
> > show at bpaste
> >
> >
> >
> >
> >                                      image
> >
> >  show at bpaste
> >  Portage 2.2.14-prefix (python
> >  3.3.3-final-0,
> >  prefix/darwin/macos/10.10/x64,
> >  gcc-4.2.1, unavailable, 14.1.0
> >  x86_64)
> >  ==================================.
> >  ..
> >
> >
> >
> >  Auf bpaste.net anzeigen             Vorschau nach Yahoo
> >
> >
> >
> >
> >
> > image
> > and the log file https://bpaste.net/show/62a0d5b0d4f4
> >
> > I will experiment further ...
-- 
bye,
Michael