Hi all, On Fri, Jan 30, 2015 at 09:04:40AM +0900, [email protected] 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 <[email protected]> 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
