Possible to build ports on 10.6.8 as universal (x86_64 + ppc64) after restoring PPC assembler?

[barracuda156]

This is a way to restore of ppc/ppc64 support into Xcode 4.2 and command line: ​https://stackoverflow.com/questions/5333490/how-can-we-restore-ppc-ppc64-as-well-as-full-10-4-10-5-sdk-support-to-xcode-4 Also: ​https://github.com/devernay/xcodelegacy

Two questions are:

1. Is it possible in principle to build ports as universal for x86_64 + ppc64 (or for all 4 archs, m32 + m64) on an Intel machine?

2. If yes, can such builds be then installed (via setting up local archive) onto a PowerPC system?

(Why I am asking this is that some ports fail to build on PowerPC natively.)

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

Two questions are:

Questions are best asked on the mailing list. The issue tracker is for tracking bugs and feature requests—things that need something to be changed somewhere and then marked resolved.

1. Is it possible in principle to build ports as universal for x86_64 + ppc64 (or for all 4 archs, m32 + m64) on an Intel machine?

I'm not aware of anyone else having attempted that before. You can try it by setting universal_archs as desired in macports.conf. If you already had any ports installed with the +universal variant when you changed the value of universal_archs, reinstall those ports so they rebuild with the new set of architectures.

2. If yes, can such builds be then installed (via setting up local archive) onto a PowerPC system?

If you're building on one OS version and wanting to bring the resulting archives over to an earlier OS version, you would need to build with the deployment target set to the older OS version. So, to build on 10.6 with the intention of bringing an archive to 10.5, set macosx_deployment_target 10.5 in macports.conf along with build_from_source always since otherwise you could receive archives from our build server that have the wrong deployment target. This setting would need to be in effect at the time that you build the affected port and all of its dependencies. (If you already had ports installed when you change this setting, rebuild them.) Not all ports honor the macosx_deployment_target setting, though that would be a bug that we would want to fix.

Universal builds should work on any system that supports one of those architectures, but few people actually test that, so you may encounter some ports that build universal but don't actually work right on the foreign architecture(s). This is especially likely if building on an Intel machine for a PowerPC machine or vice versa due to endian differences and the likelihood that the developer of the software has not anticipated such a situation. If you find such bugs, file bug reports.

[barracuda156]

Replying to ryandesign:

Thank you!

I have been able to build a port for x86_64 + ppc now:

svacchanda$ port -v installed libffi
The following ports are currently installed:
  libffi @3.4.2_2+universal (active) requested_variants='+universal' platform='darwin 10' archs='ppc x86_64' date='2022-01-13T11:49:20+0800'

The problematic part is forcing Apple gcc-4.2 in place of default LLVM.

This version works:

svacchanda$ /usr/bin/gcc-4.2 -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)

This version, which is a default, does not:

svacchanda$ gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

Using compiler.blacklist-append llvm-4.2 in port file did not help. So what I did is: sudo port -v install libffi +universal configure.compiler=gcc-4.2

Can I make a global setting enforcing Apple gcc-4.2 (not llvm-4.2), and perhaps specifically for ppc/ppc64, and not for x86_64?

[kencu (Ken)]

llvm-gcc42 was Apple's transition compiler heading to clang. It used gcc-4.2 as the front end and llvm as the back end to generate code. As llvm has never been able to generate coherent powerpc code, llvm-gcc42 never could either.

/usr/bin/gcc-4.2 (apple-gcc42) is the very old, basic compiler that comes as the system compiler on 10.5 and 10.6, and we add it to 10.4. It is useful these days only for quite basic things, as a very large percentage of the code base in macports cannot be compiled with gcc-4.2 any longer (it has no c++11 or c11 support, no thread_local support, and no support for many other modern coding constructs).

If you try to make gcc-4.2 your default compiler a large large number of things will not build.

If really wanted to make a toolchain for 10.6.8 that could generate universal x86_64 and powerpc64 code then you realistically have two choices:

1. work with Iain to get llvm finished to be able to output reliable powerpc code. This would probably be the best option, but I've been after this for five years so far :>
2. build a new gcc cross compiler that has both intel and power components, lipo them together into one big compiler (just like apple-gcc42 does) and write an updated front-end (driverdriver.c) that handles the arch flags and lipos the build products together.

Option 2 is doable today -- that is exactly what Apple did for gcc-4.2 after all, and all that code is sitting there in the apple-gcc42 port.

However, it's a fair project to complete, the front end needs to be updated, and the tooling in MacPorts would need to be all adjusted to manage it.

I have considered this at times -- it's easy enough as nothing needs to be invented -- but in the end, I decided that for me at least, there was little point.

[barracuda156]

Replying to kencu:

Thank you for replying!

1. I will bring the bigger question of building cross-compilers into discussions on Iain’s page. Ref for others who may wish to join: ​https://github.com/iains/darwin-toolchains-start-here/discussions

2. As for gcc with Macports, it does use gcc-4.2 for many ports as a default compiler. And I recall you told me that Macports’s gcc7 cannot be used to cross-compile for PowerPC, or am I wrong here? If we restrict discussion to Macports, what realistic options are there to build on 10.6.8 Intel for x86_64 + ppc(64)?

3. In any case, this is perhaps a relevant thing to know: how to specify a compiler depending on architecture? Should I use a similar way that you used with SnowLeopardPPC ports, compilers setting file? Is it even feasible to use two different compilers for arch portions of same universal binary? Or I have to simply ban llvm-gcc all through?

[kencu (Ken)]

On 10.6, there is a weird situation that happens occasionally.

People blacklist older gcc versions like this perhaps:

compiler_blacklist-append gcc-4.*

and that sometimes lets llvm-gcc-4.2 still be allowed. llvm-gcc-4.2 should almost never be used as a compiler on Macports at all for anything.

But it squeeks it's little nose in here and there to cause trouble, and perhaps there is some weird port somewhere deep in the bowels of Macports that relies on it, I haven't checked every one.

[barracuda156]

Replying to kencu:

On 10.6, there is a weird situation that happens occasionally. llvm-gcc-4.2 should almost never be used as a compiler on Macports at all for anything.

Got it, thank you! Then I will just blacklist it globally.

[barracuda156]

Replying to kencu:

2. build a new gcc cross compiler that has both intel and power components, lipo them together into one big compiler (just like apple-gcc42 does) and write an updated front-end (driverdriver.c) that handles the arch flags and lipos the build products together.

Option 2 is doable today -- that is exactly what Apple did for gcc-4.2 after all, and all that code is sitting there in the apple-gcc42 port.

Is this solution working? ​https://github.com/devernay/macportsGCCfixup

Ref from ​https://github.com/Blzut3/xcodelegacy