Most of the tools in this package has already bumpted their version on apple website ld64: portage 138.2 website 136 cctools: portage 822 website 839 libunwind: portage 30 website 35.1 dylid: portage 195.6 website 210.2.3 Please at least bump ld64's version since the current version doesn't work with =sys-devel/clang-3.2 (I have to link $EPREFIX/usr/bin/ld to /usr/bin/ld which is version 136) Reproducible: Always
Could you perhaps have a try, to see if the new versions "just compile" or not? If would greatly help me if you could do the initial toying around with the ebuild here. Thanks!
I've tried but failed since many patches needs to be modified and I'm not sure about the why each patch was needed and if they are still needed for the new version.
Versions in Developer Tools 5.1: cctools: 855 ld64: 236.3 OS X 10.9.2: libunwind: 35.3 dyld: 239.4
note to self: ld64 sources use language constructs gcc-apple doesn't grok although c++11 headers can be fetched from tr1 subdir. So, need clang to compile this.
Created attachment 393808 [details] binutils-apple-5.1 ebuild and patches I had a stab at this and came up with the attached ebuild and patches for the cctools/ld64 versions as of XCode 5.1. I started with a binutils-apple-4.5 ebuild and patches from https://github.com/fishman/timebomb-gentoo-osx-overlay/tree/master/sys-devel/binutils-apple and tried to do some cleanup (e.g. libunwind doesn't seem to be needed any more) while retaining stuff that's needed for backward compatibility. Since I'm on 10.10 right now and don't have an older box, I can't be certain, I succeeded. This ebuild should: - compile with clang as well as gcc-apple-4.2.1 - not require libcxx (at least with gcc-apple) - work with or without USE="lto" (where the latter requires a recent llvm/clang with USE="lto" installed) - run the test suite with the just compiled tools Just today I noticed that apple has released the Xcode 6.1 version of the tools. I'll give those a whirl now.
Created attachment 393814 [details] binutils-apple-6.1 and updated 5.1 ebuild and patches And here's the same for 6.1 including fixes to running the test suite so it actually picks up the newly compiled ld (didn't realise that it just calls the compiler and hopes it picks up the new ld from the patch - clang seems to have an undocumented option -ccc-install-dir that can be used to point to the ld more reliably).
Created attachment 394018 [details] updated binutils-apple-6.1 and 5.1 ebuilds and patches The attached updated ebuilds compile and seem to work fine on OS X 10.6 32bit and 10.7 and 10.10 64bit. Some minor fixes were needed for that to work. I'm currently testing them on 10.8 and 10.9 64bit. Also I added a libcxx USE flag to allow for explicitly selecting the C++ standard library to use with clang since there seem to be different defaults with different clang and OS X versions. What actually is the oldest currently (as of binutils-apple-4.3) supported OS X for prefix I would need to look out for?
Update: Tested successfully all the way down to 10.5 on Intel. Got no PPC box anymore. 32bit 64bit 10.5 fine N/A 10.6 fine fine 10.7 fine fine 10.8 fine fine 10.9 fine fine 10.10 N/A fine On 10.5 and 10.6 64bit it needs an updated libstdc++ in gcc-apple. See https://bugs.gentoo.org/show_bug.cgi?id=537348. On 10.4 it's struggling (CPU_TYPE_ARM not defined...). Anyone still using that?
Created attachment 394624 [details, diff] updated ebuilds that also work on 10.5
I successfully tested the binutils-apple-6.1 with gentoo_prefix on a Mac OS 10.10 64bit (using gcc-4.7.3).
Created attachment 394862 [details] updated ebuilds that also work on 10.4 and generally clean up everything These updated ebuilds also work on 10.4. The process of making them work there revealed some major misconceptions in how ld64 was built before. After cleanup the ebuilds should now: - use the intended cpp define and default deployment target configuration mechanism for ld64 (create_configure.sh) - produce an ld64 with proper arm and arm64 support on all versions of OS X from 10.4 to 10.10 - silence warnings about offsetof in ld64 source the same way upstream does (by ignoring :) - speed up compile time by not building a profileable libstuff that cctools don't use anyway - really do compile libstuff without debug information by default and disable dsymutil for cctools - make cctools emit correct, Gentoo-extended version information again - avoid double passing of CFLAGS to cctools via OFLAG and RC_CFLAGS - generally clean up cctools and ld64 make parameter passing - add loads of rationale to ebuilds and patches - make arm and arm64 support fully optional at build time although it's not needed currently (I thought so until the very last minute while developing) Tested on 10.4 through 10.10 with 32 and 64bit where available. Quite a number of patches (ld64-241.9-atomic-volatile.patch, ld64-241.9-cc_md5.patch, ld64-241.9-get-comm-align.patch, ld64-241.9-register-names.patch) and conditions are necessary for 10.4 only. Since that's not really a wide-spread platform on Intel, they're mainly of academic interest. In favour of maintainability I wouldn't be upset if they were dropped on inclusion in the portage tree. They should all be clearly marked. I'll try to refrain from any further updates to give everyone a chance for testing and feedback. :)
I made a slight change to set SLOT to 5 and 6 for the two ebuilds, compiling now, will see how it goes, looks good sofar!
Created attachment 394966 [details, diff] fix small ifdef bug in nolto patch In the meantime I found a very small bug in the nolto patch that would make ld64 carry on parsing arguments after printing its version information when called with only -v when compiled without LTO support: @(#)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 ld: warning: -arch not specified ld: warning: -macosx_version_min not specified, assuming 10.10 ld: no object files specified for inferred architecture x86_64 With the new patch it correctly exits after printing "configured to support ...". But only if called directly because ld wrapper always adds the search_paths_first option to the command line even if there's just a -v so it always keeps on parsing and complaining as before: michael@osx1010:~ # ld64 -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 Library search paths: /Users/michael/nobak/gentoo/usr/x86_64-apple-darwin14/lib/gcc /Users/michael/nobak/gentoo/usr/x86_64-apple-darwin14/lib /Users/michael/nobak/gentoo/usr/lib /Users/michael/nobak/gentoo/lib /usr/lib /usr/local/lib Framework search paths: /Library/Frameworks/ /System/Library/Frameworks/ ld: warning: -arch not specified ld: warning: -macosx_version_min not specified, assuming 10.10 ld: no object files specified for inferred architecture x86_64
It seems to work on my old laptop (10.7.5), so I've committed this as is. Thanks for your hard work!
ok, lto fix committed now too :)
