iains
assorted fixes for powerpc-apple-darwin9
system info:
% gcc -dumpmachine powerpc-apple-darwin9 % gcc -dumpversion 10.1.0 % ld -v @(#)PROGRAM:ld PROJECT:ld64-97.17 (Gentoo binutils-apple-3.2.6) Library search paths: /Volumes/Scratch/Gentoo/Leopard/usr/lib /Volumes/Scratch/Gentoo/Leopard/lib /usr/lib /usr/local/lib Framework search paths: /Library/Frameworks/ /System/Library/Frameworks/ ld: warning: -arch not specified ld: no object files specified for inferred architecture ppc
Um... this seems like kind of a lot? Do they all really need to be combined into a single PR?
hmmyeah, not sure what went wrong here, these are now fixes for Darwin in general.
also it looks like this includes PR #8 as well? It'd probably be better to get that one merged separately first...
hmm I have no idea how I missed this PR (somehow I got no email) only spotted because of the #7 patch.
(a) I guess this is still relevant? (b) would it be possible to split it into pieces? [GH does not, AFAIU, allow me to ack individual commits while not merging the whole branch].. Ideally a branch should address a single topic.
Ok, I should probably revive this then and make it more consumable. Of course you can cherry pick commits if you see something useful. I was under the impression there was no interest in it, and I think I pushed additional fixes to the same branch or something. I'll look into cleaning this up.
sadly, this is not $dayjob - it's not lack of interest, just very limited time :(
Actually, I am willing to cherry-pick individual commits - if that suits you.
For information: I have a much more compatible xtools branch for OSX-10.4 - 10.8 (which includes the ability to run the ld64 tests) - it is buildable starting from Apple's gcc-4.2.1. This will become xtools-0.7.0 and will be recommended for all archs in that OS range)
I am hoping to get some cycles on xtools in November.
Same here, and I frankly forgot about this. Certainly looking forward to using a newer xtools (0.7.0 being newer than 2.2.4?). It's the default linker on Gentoo for macOS, except arm64 where it doesn't work.
Same here, and I frankly forgot about this. Certainly looking forward to using a newer xtools (0.7.0 being newer than 2.2.4?).
The idea is to try to move to building whole toolchains that are matched to the OS versions they are trying to support - so that:
- 0.7.0 would be appropriate for 10.4-10.8
- 2.2.4-some-release-version would be appropriate for 10.9 - 1011
- something based on Xcode 10.3 sources for 10.12-10.14
- etc.
"One-size-fits-all" is an attractive idea - but it gets increasingly complex to maintain.
e.g. - One issue is that 32b support got ripped out - so that if we try to support powerpc on "latest available" Xcode sources we are not only adding back powerpc but also the 32b stuff. Not impossible (it's all "just code") but time taken could be significant.
edit: A secondary motivation is to pick the most modern toolchain components that we can realistically bootstrap on the target using only the available Xcode version (so, for example, on 10.5 we need to start from gcc-4.2.1 + ld64-85.2.1 + dwarfutils dsymutil and use that to bootstrap a capable C++11/4 toolchain). Moving much beyond ld64-236 really means using a C++11 compiler (hence the recommendation to use 0-7-0 for the platform versions that do not have a usable C++11 compiler installed).
It's the default linker on Gentoo for macOS, except arm64 where it doesn't work.
Likewise, we have to make changes to the latest published - (Xcode 12.0 sources, currently) and then add that to the arm64 braches (also here) - although we are trying to upstream the arm64 support.