search

iains / gcc-darwin-arm64

GCC master branch for Darwin with experimental support for Arm64. Currently GCC-15.0.0 [September 2024]
GNU General Public License v2.0
269 stars 33 forks source link

configuring with arm64-apple-darwin20 doesn't work yet #36

Closed iains closed 3 years ago

iains commented 3 years ago

I'm not sure if this is a major objective (perhaps a 'nice to have') but it also means that the sub-directories have to understand arm64-apple-darwin (which would mean updating GMP/MPFR/MPC/ISL and libcody, at minimum to config.sub/guess that understand arm64-apple-darwin).

michaelld commented 3 years ago

I went ahead and moved the gcc-devel port for ARM64 to use the triplet aarch64-apple-darwin20 since it works without modifying the GCC source in any way (e.g., copying the top-level config.* scripts into libcody/build-aux). So, all is well again on our end with respect to this issue.

I believe my original issue boils down to the following: the top-level config.* scripts can take either arm64-* or aarch64-* and I think the former is "aliased" to the latter. BUT: the triplet as provided is then passed on to the subdirectory config.* scripts, and those scripts for libcody are old enough to not parse arm64-* but new enough to parse aarch64-* ... which is why the latter works as you have been testing & I moved our port to using.

When I copy the top-level config.* scripts into libcody, then both do the "aliasing" correctly & this is why in this situation our port worked with the original arm64-* triplet. The updated config.* scripts might be needed in other subdirectories ... in MacPorts we use external dependencies where reasonably possible, which includes for the GCC ports.

iains commented 3 years ago

This needs some more checking in general there are other configuration patterns... ... e.g. my habit is to build GMP et. al. (i.e. the GCC prerequisites) in-tree so that they are bootstrapped with the compiler. There are also various other cases that Darwin doesn't generally use, but which are used by (say) Linux. It all takes time and testing across multiple platforms ....

(for the record, from the email discussion):

When I began work on this port, I consulted the maintainers of the config. stuff about the canonical port triple [for arm64 apple ports]. It seemed that the decision had already been made that this would be `aarch64-apple-darwin` (there were already apparently uses of this 'in the wild') - therefore, I stuck to that decision.

IMO the most important thing is for user-facing stuff to be the same as the clang toolchain, where possible. So responding to -arch arm64 where needed is counted as essential...

...but, for my 0.02GBP, I don't count configuration parameters as 'user facing'; one assumes that someone who is adjusting configuration parameters is ( or believes themselves to be ;) ) knowledgable about the consequences - so that configuring the "arm64-apple-darwin" case is a 'nice to have' and not so much essential as some of the other work (given perennial limited resources to work on the port).

iains commented 3 years ago

of course, someone who wants to produce a patch and post it to patches@ for review would be most welcome!

iains commented 3 years ago

this is now "fixed".

NOTE aarch64-apple-darwinNN is still the canonical configuration name (that isn't going to change, since it was already decided before the GCC port started).

so configuration with --{target, host, build}=arm64-apple-darwin20 will work - but (internally) the triple is still aarch64-apple-darwin20.