I've updated the binutils-apple ebuilds for Xcode 7.0, 7.1 and 7.2. I also had changes sitting around for resurrecting PPC support based on my work at https://github.com/michaelweiser/ld64 (and incidentally support for OS X < 10.6) in all versions since 4.3 and merged them in for your consideration. I also updated the ebuilds for the recent change in LLVM to refer to all libs via @rpath which broke ld64 when compiled with USE="lto". Reproducible: Always
Created attachment 434004 [details] Updated ebuilds and patches.
ld64-128.2-Makefile-3 doesn't exist, did you forget to tar it, or should it be ld64-128.2-Makefile-2 (which exists)?
same for ld64-236.3-Makefile-2 and ld64-253.3-Makefile-2 also: * Failed Patch: binutils-apple-4.3-lto-prefix.patch ! * ( /var/tmp/portage/sys-devel/binutils-apple-4.3-r2/work/binutils-apple-4.3-lto-prefix.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/sys-devel/binutils-apple-4.3-r2/temp/binutils-apple-4.3-lto-prefix.patch.out =============================================== checking file libstuff/llvm.c Hunk #1 FAILED at 35. Hunk #3 FAILED at 105. 2 out of 3 hunks FAILED checking file libstuff/lto.c checking file libstuff/Makefile checking file Makefile checking file misc/Makefile would it be easier to create one bit patchbomb instead? I have to store the patches separately anyway, since they are too big to be stored in the tree.
same: * Failed Patch: binutils-apple-6.3-lto-prefix.patch ! * ( /var/tmp/portage/sys-devel/binutils-apple-5.1-r1/work/binutils-apple-6.3-lto-prefix.patch ) I've committed the ebuilds, but masked by keywords so we can complete them easily.
Created attachment 434436 [details] Updated ebuilds and patches > ld64-128.2-Makefile-3 doesn't exist, did you forget to tar it, or should it be ld64-128.2-Makefile-2 (which exists)? > same for ld64-236.3-Makefile-2 and ld64-253.3-Makefile-2 I'm so sorry. I seem to have grabbed an old version of that tarball. The attached one should contain everything that's needed. BTW: files/ld64-136-Makefile has been redundant for some time, it seems. > would it be easier to create one bit patchbomb instead? Ah, well, I've got no idea what a patchbomb is. Just a tarball of my changed sys-devel/binutils-apple? Is there some helper script around that determines differing, unreferenced and new files in ${FILESDIR} between overlay and tree? That would certainly help in determining the files to send more smartly than the one-liner I'm using currently.
with that tar: * Failed Patch: binutils-apple-6.3-lto-prefix.patch ! * ( /var/tmp/portage/sys-devel/binutils-apple-5.1-r1/work/binutils-apple-6.3-lto-prefix.patch ) * the rest seems to apply fine now.
(In reply to Michael Weiser from comment #5) > > would it be easier to create one bit patchbomb instead? > > Ah, well, I've got no idea what a patchbomb is. Just a tarball of my changed > sys-devel/binutils-apple? What I meant was a tar or single patch (huge) for each of the releases. What I now did was create tars for each release, with a delta (addition) of patches.
Created attachment 434512 [details, diff] lto prefix patch for binutils-apple-5.1 > Failed Patch: binutils-apple-6.3-lto-prefix.patch Uh, yes, another screw-up on my part - test-merged 5.1, not 5.1-r1. Attached is the necessary patch for 5.1. Adjusted ebuild for 5.1 forthcoming. There it's just replacing epatch.*6.3-lto-prefix by 5.1-lto-prefix.
Created attachment 434514 [details] updated ebuild for binutils-apple-5.1
(In reply to Fabian Groffen from comment #7) > What I now did was create tars for each release, with a delta (addition) of > patches. That sounds like the most flexibile way to me and is how binutils and gcc do it with their patchsets, isn't it?
Yes exactly, thanks. I'll update the tar for 5.1 and the ebuild later to include your updated patch. For the time being 5.1 remains masked, but this doesn't seem like such a big deal for now (7.2 installed fine here, with linking confirmed to work fine too).
ok, finally done, thanks for all the work!
Thanks for accepting and integrating it!
