iains / gcc-10-branch

[April 2021] 10.3 plus Darwin additions, initial 10.3 Arm64.
GNU General Public License v2.0
7 stars 2 forks source link

Consider adding a case of 10a190 into gcc/config/rs6000/darwin.h in a neat way #10

Open barracuda156 opened 5 months ago

barracuda156 commented 5 months ago

@iains Iain, I would like to request you to consider having this fixed in some acceptable way on your branch (we do not require to convince upstream to merge it, if that is problematic).

Since you have added support for Rosetta into rs6000 config, there are only two issues which prevent gcc10+ from building on 10.6 ppc (10a190):

  1. We need to link to libgcc_s.10.5.dylib and libgcc_eh (instead of libemutls_w) here: https://github.com/gcc-mirror/gcc/blob/0e64bbb8823f7b3757befc878ed177dfb59943d1/gcc/config/darwin.h#L548-L564

  2. The hack for gfortran which is added for 10.6 is not needed on 10.6 ppc and, as I recall, breaks some dependents (I think the build itself succeeds, but using it is problematic): https://github.com/gcc-mirror/gcc/blob/0e64bbb8823f7b3757befc878ed177dfb59943d1/gcc/config/darwin.h#L419

What I do for my builds is 1) replace 10.6 with 10.7 and 2) delete that line with -ld10-uwfef. This works perfectly fine, AFAICT, compiler is robust, but it is not portable solution and cannot be accepted either by GCC or by Macports.

It may be in fact okay to change both in rs6000-specific config to these values, since I think both changes work fine on Rosetta as well, but they are not required for it. To apply these values only to 10.6 ppc, we could implement detecting whether the target is a developer build. There are at least two ways, perhaps:

  1. Use a triple, since a developer build with have a suffix like powerpc-apple-darwin10.0.0d2.
  2. Check a kernel header which sets defines for pre-release builds: /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/libkern/version.h (version_stage there).

Or maybe you have a better solution in mind? I will test whatever you suggest to.

I open this specifically for gcc10 branch, since it is needed to build any higher version of GCC on older systems, so fixing it cannot be bypassed. And while I may be able to add gcc-powerpc port to Macports which then can have PowerPC-specific fixes (including but not limited to 10.6 ppc), it cannot be built unless gcc10-bootstrap is fixed for 10.6 ppc, and that cannot be fixed, unless the fix comes from your branch (which Macports uses to generate patches).

Ken is also fine with having 10.6 ppc support patch added, as long as it comes from your branch.

P. S. Strictly speaking, the problem has nothing to do with PowerPC and applies to all pre-release builds of 10.6 (up to some point). At least it is just as valid for 10a190 on i386. Though perhaps no one needs it on Intel for practical purposes, since 10.6.8 is there. If you would wish to test it, on Intel 10a190 should be installable normally from Apple-supplied ISO (without any hacks to Boot and kexts). I did that on a MacMini CoreDuo, it worked fine. This should work: 10.6_snowleopard_10a190_clientdvd.iso from https://macintoshgarden.org/apps/mac-os-x-snow-leopard-powerpc-the-early-106-developer-builds

iains commented 5 months ago

I'll look into these issues before releasing 10.5 (10.5 is going to be a big release, with a lot of back ported fixes) - since it's the last thing that can be bootstrapped with system tools.

barracuda156 commented 5 months ago

@iains Thank you very much!