When installing llvm 3.4.2 and 3.5.0 on OS X 10.8/9 in a 32bit prefix, I got reproducible hangs when it started to compile compiler-rt. While investigating, I found that compiler-rt runs the compiler and other tools via xcrun. This makes it pick up the system's compiler and SDKs instead of the one that was just compiled by the ebuild. This doesn't seem a good idea to me on principle. Also, disabling use of the system's compiler also made my hangs disappear. I suspect that it has something to do with calling the system's 64bit xcrun and clang from a 32bit prefix - but that's for a different bug report, if it continues to crop up. Disabling use of the system SDKs indirectly also disables compilation of the runtime for iphonesimulator. Also, compilation fails on 10.5 as discussed in this MacPorts ticket: https://trac.macports.org/ticket/43353. Finally, the old-linker patch has not made it from 3.4.2's ebuild into 3.5.[01]. But it isn't necessary any more if >= sys-devel/binutils-5.1 from the following bug is in use: https://bugs.gentoo.org/show_bug.cgi?id=473068. Reproducible: Always
Created attachment 394604 [details, diff] patch to the ebuilds of 3.4.2 and 3.5.[01] that fixes all three problems on darwin (for me)
binutils-apple-5.1 and -6.1 are in the tree now. So they can "legally" be required by the ebuilds.
so, can we close this bug, or do you want to update the requirement to 6.1?
5.1 should be fine. It's tested and supports everything clang needs.
(In reply to Michael Weiser from comment #4) > 5.1 should be fine. It's tested and supports everything clang needs. ok, then I'll drop the darwin-old-linker patch at the same time
Then don't forget to update the dependency in 3.4.2 as well. I didn't because the old-linker-patch was in there and working.
I've done all of them :) I'm just a bit lost on the remaining changes to be done here. I want the independency, but i wonder about the asan patch, why can't that one be unconditional? Side note, I see in the no-asan patch a remark that 10.6 has a bug in its ranlib, and therefore it strips arm targets. This is of course non-sense in Prefix. I guess a review is necessary to rid it from more of those "assumptions". (If you want all targets to be enabled, that is.)
(In reply to Fabian Groffen from comment #7) > I'm just a bit lost on the remaining changes to be done here. I want the > independency, but i wonder about the asan patch, why can't that one be > unconditional? The asan patch disables building of that part of the runtime. No idea what it does but the MacPorts bug report says it shouldn't be built on < 10.6 because it can't work there. But everywhere else it should be built and does work. So the block + if [[ "${CHOST##*-darwin}" -le 9 ]] ; then + # https://trac.macports.org/ticket/43353 + epatch "${FILESDIR}"/${PN}-3.4.2-leopard-no-asan.patch fi disables it only on < 10.5. The rest of the patch is for disabling use of the host tools: sed -i -e "/^CFLAGS /s@-Werror@-I${EPREFIX}/usr/include@" \ + -e "s@override CC@CC@" \ keeps the CC variable from being overridden with a clang found via xc-run. And + if [[ ${CHOST} == *darwin* ]] ; then + # Keep compiler-rt from using the system's compiler and SDKs. + # This also disables the iphonesimulator target. + MAKEARGS+=( + DSYMUTIL=dsymutil + LIPO=lipo + STRIP=strip + RANLIB=ranlib + AR=ar + IOSSIM_SDK_PATH= + ACTIVE_SDK_PATH= + ) + fi forces the paths to the SDKs to be undefined so they aren't used and the tools not to be searched using xc-run either but the search path instead. > Side note, I see in the no-asan patch a remark that 10.6 has a bug in its > ranlib, and therefore it strips arm targets. This is of course non-sense in > Prefix. I guess a review is necessary to rid it from more of those > "assumptions". (If you want all targets to be enabled, that is.) Here's the whole text: # Darwin 10.6 has a bug in cctools that makes it unable to use ranlib on our ARM # object files. If we are on that platform, strip out all ARM archs. We still # build the libraries themselves so that Clang can find them where it expects # them, even though they might not have an expected slice. ifneq ($(shell test -x /usr/bin/sw_vers && sw_vers -productVersion | grep 10.6),) UniversalArchs.ios := $(filter-out armv7, $(UniversalArchs.ios)) UniversalArchs.cc_kext := $(filter-out armv7, $(UniversalArchs.cc_kext)) UniversalArchs.cc_kext_ios5 := $(filter-out armv7, $(UniversalArchs.cc_kext_ios5)) UniversalArchs.profile_ios := $(filter-out armv7, $(UniversalArchs.profile_ios)) endif I agree. And looking at that osversion-conditional I think our no-asan patch could be a lot nicer and would not need to be conditional in the ebuild. I'll get back to you with an updated ebuild. In the meantime you could add the non-host-tools bits if you wanted. :)
Created attachment 395424 [details, diff] collection of darwin prefix support patches The attached patch files and patch to the ebuilds - fix compilation issues on OS X 10.4 (macros not defined and dyld not understanding @rpath library references) - disable compilation of asan and ubsan runtime libraries on OS X older than 10.6 using nice make conditional logic - enable running ar on some arm runtime libraries because prefix's ar is current enough to do so even on OS X < 10.7 - disable the default search paths for the systems libstdc++ headers on Darwin - disable use of the system's compiler and tools to compile runtime libraries. SDKs are still enabled at the moment, so iphonesimulator libraries are built. I'm looking into disabling only the OS X SDK but leaving IOS/arm enabled. BTW: Turns out, clang doesn't do any gcc-like bootstrap. It just compiles itself and its libraries using any host compiler. Now at least the prefix's compiler should be used consistently. - extend the Gentoo runtime GCC detection patch to add a GCC installation detector to the Darwin clang driver to detect the prefix's GCC installation based on gcc-config files in $EPREFIX/etc/env.d/gcc. Based on that the libstdc++ include and linker paths are set up the same way gcc-apple does and clang does on Linux. With this detector in place all other kinds of special cases can be tackled. I am somewhat uncertain on the actual linker paths to add because there are two directories carrying libstdc++: ${EPREFIX}/usr/<triple>/lib/gcc - has libstdc++.6.dylib but no libstdc++.dylib - is not owned by any package!? where does it come from? - is already forced onto the linker path by the prefix ld wrapper - would need putting -lstdc++.6 onto the linker command line by cland ${EPREFIX}/usr/lib/gcc/<triple>/<version> - has libstdc++.dylib - is similarly used for finding libstdc++ by gcc-4.9 on Gentoo Linux I wonder if there is some historic or cross-compile-support reason for using either one or the other. I've opted for the latter for now but left commented-out code in the patch outlining the other option.
upstream bugs: http://llvm.org/bugs/show_bug.cgi?id=22452 http://llvm.org/bugs/show_bug.cgi?id=22453 http://llvm.org/bugs/show_bug.cgi?id=22438 http://llvm.org/bugs/show_bug.cgi?id=22454
Created attachment 395494 [details] updated collection of darwin prefix support patches
Overtaken by reality: works well enough for bootstrapping into a clang environment with libc++.
