[bug] ld doesn't support ppc

ChrisNonyminus commented

2022-03-03 22:56:57 -06:00

(Migrated from github.com)

When cctools is configured to target powerpc-apple-darwin, as assembles powerpc assembly without issue, but ld will not link it.

chrisnonyminus@DESKTOP-JLMSNKL:~/test/helloworld$ powerpc-apple-darwin-ld a.out -o test -arch ppc
ld: unknown/unsupported architecture name for: -arch ppc
chrisnonyminus@DESKTOP-JLMSNKL:~/test/helloworld$ powerpc-apple-darwin-ld -v
@(#)PROGRAM:ld  PROJECT:ld64-609
BUILD 17:46:02 Mar  3 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
LTO support using: LLVM version 10.0.0 (static support for 26, runtime is 26)```

When cctools is configured to target powerpc-apple-darwin, as assembles powerpc assembly without issue, but ld will not link it. ``` chrisnonyminus@DESKTOP-JLMSNKL:~/test/helloworld$ powerpc-apple-darwin-ld a.out -o test -arch ppc ld: unknown/unsupported architecture name for: -arch ppc chrisnonyminus@DESKTOP-JLMSNKL:~/test/helloworld$ powerpc-apple-darwin-ld -v @(#)PROGRAM:ld PROJECT:ld64-609 BUILD 17:46:02 Mar 3 2022 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS) LTO support using: LLVM version 10.0.0 (static support for 26, runtime is 26)```

👍 1

Gcenx commented

2022-03-18 08:53:04 -05:00

(Migrated from github.com)

ld64-127 was the last version from Apple to support ppc

Wohlstand commented

2023-01-16 21:59:56 -06:00

(Migrated from github.com)

Recently I attempted to review the difference between the current ld64 and the ld64-127.2, and I attempted to backport PowerPC-related parts but hadn't completed that yet. On another side, I want to get a shot to make the ld64-127 work here. How much the modded ld64 is different from the official ld64?

👍 1

Wohlstand commented

2023-01-16 22:02:33 -06:00

(Migrated from github.com)

P.S. I attempting to make a cross-compiler toolchain to run my experimental stuff on my Mac Mini G4, however, it's a pain to build the code on it because of a very weak processor, and therefore a cross-compiler for modern Linux should simplify this. I built everything except GCC: it fails to build the thing because of the ld64...

👍 2

Wohlstand commented

2023-01-16 23:53:17 -06:00

(Migrated from github.com)

I made the first attempt here: https://github.com/tpoechtrager/cctools-port/compare/master...Wohlstand:cctools-port:ppc-revive
I had to compare two versions: 127.2 and 128.2 to see what parts of the code were changed in order to remove PowerPC support. So, I attempted to restore that code to the latest version (which appears in this repository here). Trying some to verify its work and make the thing work...

I made the first attempt here: <https://github.com/tpoechtrager/cctools-port/compare/master...Wohlstand:cctools-port:ppc-revive> I had to compare two versions: 127.2 and 128.2 to see what parts of the code were changed in order to remove PowerPC support. So, I attempted to restore that code to the latest version (which appears in this repository here). Trying some to verify its work and make the thing work...

🎉 2

VariantXYZ commented

2025-01-20 22:46:56 -06:00

(Migrated from github.com)

@Wohlstand , it's two years later, but I did try your branch and was able to successfully build cctools for powerpc-apple-darwin8, but if I try to use this to build something like 'gcc' seems to fail to actually link against anything in the 10.4 SDK (ld can t map file errno 22 dylib1.o for architecture ppc). Were you ever able to get a cross-compiler targeting powerpc-apple-darwin8 working?

Edit: Ah, actually, it seems like by simply using lipo to extract the mach-o ppc binaries out, ld can use them, this can work!

@Wohlstand , it's two years later, but I did try your branch and was able to successfully build cctools for powerpc-apple-darwin8, but if I try to use this to build something like 'gcc' seems to fail to actually link against anything in the 10.4 SDK (`ld can t map file errno 22 dylib1.o for architecture ppc`). Were you ever able to get a cross-compiler targeting powerpc-apple-darwin8 working? Edit: Ah, actually, it seems like by simply using `lipo` to extract the mach-o ppc binaries out, ld can use them, this can work!

Wohlstand commented

2025-01-21 01:26:49 -06:00

(Migrated from github.com)

Hello!
I didn't yet finished my experiment, and the other problem that GCC is tricky to build. I did all the work on Ubuntu 20.04, and it was close to work, but on Ubuntu 22.04 it now fails (gcc itself) to build even worse for unknown reasons, even I trying to build the same version (Maybe I should build older GCC version for native Linux then? 🤔).

Edit: Ah, actually, it seems like by simply using lipo to extract the mach-o ppc binaries out, ld can use them, this can work!

I built the custom Apple's LD thing, and backported support for PPC from old version of ld to new. And even more tricky thing, that when I building GCC cross-compiler to macOS on Linux host, it gets confused how LD should behave (I mean build scripts of GCC itself).

Hello! I didn't yet finished my experiment, and the other problem that GCC is tricky to build. I did all the work on Ubuntu 20.04, and it was close to work, but on Ubuntu 22.04 it now fails (gcc itself) to build even worse for unknown reasons, even I trying to build the same version (Maybe I should build older GCC version for native Linux then? 🤔). > Edit: Ah, actually, it seems like by simply using lipo to extract the mach-o ppc binaries out, ld can use them, this can work! I built the custom Apple's LD thing, and backported support for PPC from old version of ld to new. And even more tricky thing, that when I building GCC cross-compiler to macOS on Linux host, it gets confused how LD should behave (I mean build scripts of GCC itself).

🎉 1

Un1q32 commented

2025-01-21 09:18:59 -06:00

(Migrated from github.com)

For testing I would recommend using Clang 7.1.0 (the last version to support ppc darwin). The build process is much simpler than GCC's. They also have prebuilt binaries on llvm.org for it, they require ncurses 5 though so you'll need to build that.

For testing I would recommend using Clang 7.1.0 (the last version to support ppc darwin). The build process is much simpler than GCC's. They also have [prebuilt binaries](https://github.com/llvm/llvm-project/releases/download/llvmorg-7.1.0/clang+llvm-7.1.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz) on llvm.org for it, they require ncurses 5 though so you'll need to build that.

👀 1

VariantXYZ commented

2025-01-21 11:42:49 -06:00

(Migrated from github.com)

I built the custom Apple's LD thing, and backported support for PPC from old version of ld to new. And even more tricky thing, that when I building GCC cross-compiler to macOS on Linux host, it gets confused how LD should behave (I mean build scripts of GCC itself).

I actually have your cctools ppc-review branch and GCC 13.3 building and compiling/linking target binaries, as mentioned I needed to forcibly extract the ppc binaries out of the SDK with the cctools lipo (you do have to rebuild crt1.o if you're using the 10.4 SDK but the 10.5 SDK should work fine if you target 10.4 specifically):

    cd $TARGET_PREFIX/$MAC_SDK_VERSION.sdk/usr/lib
    for i in **/*.dylib **/*.a **/*.o; do
      if file "$i" | grep -q "for architecture ppc)"; then
        mv $i $i.universal
        $TARGET_PREFIX/bin/$TARGET-lipo -thin ppc $i.universal -output $i
      elif file "$i" | grep -q "for architecture ppc7400)"; then
        mv $i $i.universal
        $TARGET_PREFIX/bin/$TARGET-lipo -thin ppc7400 $i.universal -output $i
      fi
    done

Now I'm trying to figure out why ld crashes when debug information is requested (-g passed by the driver). My current theory is that it's this issue with ld not having sufficient stack size by default, but I'll need to dig in when I have time, maybe later tonight.

% powerpc-apple-darwin8-gcc -O2 -g -o conftest.o conftest.c         
powerpc-apple-darwin8-gcc: internal compiler error: Segmentation fault: 11 signal terminated program collect2
Please submit a full bug report, with preprocessed source (by using -freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.

vs

% powerpc-apple-darwin8-gcc -O2 -o conftest.o conftest.c 
% file conftest.o
conftest.o: Mach-O executable ppc

conftest.c (from libpng) is just:

/* confdefs.h */
#define PACKAGE_NAME "libpng"
#define PACKAGE_TARNAME "libpng"
#define PACKAGE_VERSION "1.6.46.git"
#define PACKAGE_STRING "libpng 1.6.46.git"
#define PACKAGE_BUGREPORT "png-mng-implement@lists.sourceforge.net"
#define PACKAGE_URL ""
#define PACKAGE "libpng"
#define VERSION "1.6.46.git"
/* end confdefs.h.  */
int
main (void)
{
  ;
  return 0;
}

It seems to work if I use the old XCode PPC ld from 3.2, but that locks me into using a Mac instead of like... a Linux docker image running on GHA :P.

If we can figure this last bit out, then it means we'll have a modern-enough cross-compiler for powerpc-apple-darwin8 (Mac OS X Tiger on PPC).

> I built the custom Apple's LD thing, and backported support for PPC from old version of ld to new. And even more tricky thing, that when I building GCC cross-compiler to macOS on Linux host, it gets confused how LD should behave (I mean build scripts of GCC itself). I actually have your cctools ppc-review branch and GCC 13.3 building and compiling/linking target binaries, as mentioned I needed to forcibly extract the ppc binaries out of the SDK with the cctools lipo (you do have to rebuild crt1.o if you're using the 10.4 SDK but the 10.5 SDK should work fine if you target 10.4 specifically): ``` cd $TARGET_PREFIX/$MAC_SDK_VERSION.sdk/usr/lib for i in **/*.dylib **/*.a **/*.o; do if file "$i" | grep -q "for architecture ppc)"; then mv $i $i.universal $TARGET_PREFIX/bin/$TARGET-lipo -thin ppc $i.universal -output $i elif file "$i" | grep -q "for architecture ppc7400)"; then mv $i $i.universal $TARGET_PREFIX/bin/$TARGET-lipo -thin ppc7400 $i.universal -output $i fi done ``` Now I'm trying to figure out why ld crashes when debug information is requested (`-g` passed by the driver). My current theory is that it's [this issue with ld not having sufficient stack size by default](https://github.com/NixOS/nixpkgs/issues/149692#issuecomment-1405348679), but I'll need to dig in when I have time, maybe later tonight. ``` % powerpc-apple-darwin8-gcc -O2 -g -o conftest.o conftest.c powerpc-apple-darwin8-gcc: internal compiler error: Segmentation fault: 11 signal terminated program collect2 Please submit a full bug report, with preprocessed source (by using -freport-bug). See <https://gcc.gnu.org/bugs/> for instructions. ``` vs ``` % powerpc-apple-darwin8-gcc -O2 -o conftest.o conftest.c % file conftest.o conftest.o: Mach-O executable ppc ``` conftest.c (from libpng) is just: ``` /* confdefs.h */ #define PACKAGE_NAME "libpng" #define PACKAGE_TARNAME "libpng" #define PACKAGE_VERSION "1.6.46.git" #define PACKAGE_STRING "libpng 1.6.46.git" #define PACKAGE_BUGREPORT "png-mng-implement@lists.sourceforge.net" #define PACKAGE_URL "" #define PACKAGE "libpng" #define VERSION "1.6.46.git" /* end confdefs.h. */ int main (void) { ; return 0; } ``` It seems to work if I use the old XCode PPC ld from 3.2, but that locks me into using a Mac instead of like... a Linux docker image running on GHA :P. If we can figure this last bit out, then it means we'll have a modern-enough cross-compiler for powerpc-apple-darwin8 (Mac OS X Tiger on PPC).

👀 1

Un1q32 commented

2025-01-21 22:03:52 -06:00

(Migrated from github.com)

Once LLVM 20 rc1 is out I'll try to add back support for PPC darwin into LLVM 20, no promises though, I'm not that experienced with the LLVM codebase yet or compilers in general, but being able to use Clang instead of GCC would be great for me personally.

I probably shouldn't announce projects that I have no idea if I can complete but oh well.

Once LLVM 20 rc1 is out I'll try to add back support for PPC darwin into LLVM 20, no promises though, I'm not that experienced with the LLVM codebase yet or compilers in general, but being able to use Clang instead of GCC would be great for me personally. I probably shouldn't announce projects that I have no idea if I can complete but oh well.

Un1q32 commented

2025-01-21 22:22:22 -06:00

(Migrated from github.com)

This guy seems to have made powerpc darwin work in LLVM 8, that's the newest I can find online https://github.com/iains/LLVM-8-Branch

VariantXYZ commented

2025-01-22 12:40:26 -06:00

(Migrated from github.com)

Yeah, I'm using his gcc 13.3 branch as well.

Anyway, built dsymutil with llvm-7 and it seemed to do the trick.

Anyway, for anyone who might benefit, I created a Dockerfile to create the cross compiler: https://github.com/VariantXYZ/gcc-powerpc-apple-darwin8/blob/main/.github/workflows/Dockerfile

Unfortunately, I'm struggling to build it in GHA 🥲

Yeah, I'm using his gcc 13.3 branch as well. Anyway, built dsymutil with llvm-7 and it seemed to do the trick. Anyway, for anyone who might benefit, I created a Dockerfile to create the cross compiler: https://github.com/VariantXYZ/gcc-powerpc-apple-darwin8/blob/main/.github/workflows/Dockerfile Unfortunately, I'm struggling to build it in GHA 🥲

👍 2

Un1q32 commented

2025-01-22 12:52:23 -06:00

(Migrated from github.com)

Is there a reason to not use GCC 14? Also why do you rebuild the Csu when you can just use the one in the SDK?

VariantXYZ commented

2025-01-22 13:59:50 -06:00

(Migrated from github.com)

The build finally succeeded: https://github.com/VariantXYZ/gcc-powerpc-apple-darwin8/pkgs/container/gcc-powerpc-apple-darwin8

Is there a reason to not use GCC 14

I just started with 13.3 and forgot 14 existed, actually.

Also why do you rebuild the Csu when you can just use the one in the SDK?

We're using the 10.4u SDK which has this issue https://github.com/tpoechtrager/osxcross/issues/50#issuecomment-149013354

10.5 works too, but I was stubbornly trying to see if I could get just 10.4u working.

For reference, I documented the general reasoning for everything here: https://vxyz.me/00003.html

The build finally succeeded: https://github.com/VariantXYZ/gcc-powerpc-apple-darwin8/pkgs/container/gcc-powerpc-apple-darwin8 > Is there a reason to not use GCC 14 I just started with 13.3 and forgot 14 existed, actually. > Also why do you rebuild the Csu when you can just use the one in the SDK? We're using the 10.4u SDK which has this issue https://github.com/tpoechtrager/osxcross/issues/50#issuecomment-149013354 10.5 works too, but I was stubbornly trying to see if I could get just 10.4u working. For reference, I documented the general reasoning for everything here: https://vxyz.me/00003.html

🎉 1

VariantXYZ commented

2025-01-25 17:14:56 -06:00

(Migrated from github.com)

Once LLVM 20 rc1 is out I'll try to add back support for PPC darwin into LLVM 20

I think this is definitely the 'cleanest' solution that will probably allow for keeping everything as modern as can be, but for the interim, I think GCC 14.2 + 10.5 SDK targeting 10.4 works (I'm trying to fix my iBook so I can actually test things...). Images for both are here: https://github.com/VariantXYZ/gcc-powerpc-apple-darwin8/pkgs/container/gcc-powerpc-apple-darwin8/versions

I have some workflows here that show how to use them: https://github.com/VariantXYZ/gbdev-powerpc-apple-darwin8/tree/main/.github/workflows

I'm trying to setup QEMU for now to properly test things...

> Once LLVM 20 rc1 is out I'll try to add back support for PPC darwin into LLVM 20 I think this is definitely the 'cleanest' solution that will probably allow for keeping everything as modern as can be, but for the interim, I _think_ GCC 14.2 + 10.5 SDK targeting 10.4 works (I'm trying to fix my iBook so I can actually test things...). Images for both are here: https://github.com/VariantXYZ/gcc-powerpc-apple-darwin8/pkgs/container/gcc-powerpc-apple-darwin8/versions I have some workflows here that show how to use them: https://github.com/VariantXYZ/gbdev-powerpc-apple-darwin8/tree/main/.github/workflows I'm trying to setup QEMU for now to properly test things...

Un1q32 commented

2025-01-25 17:58:56 -06:00

(Migrated from github.com)

I saw that ppc64 with LLVM 7 doesn't work, there will probably be a lot of issues beyond that since the LLVM code for ppc darwin hasn't been updated in like 6 years and my only experience with the LLVM codebase is a few extremely minor patches. Plus I've had serious issues with compiling for OSX 10.5 x86 and iOS 2 with Clang. I imagine GCC will probably be the best option for a while.

barracuda156 commented

2025-01-26 06:57:06 -06:00

(Migrated from github.com)

This guy seems to have made powerpc darwin work in LLVM 8, that's the newest I can find online https://github.com/iains/LLVM-8-Branch

Rather use his llvm-7.1.1 (or my port of it for MacPorts). It is better tested than llvm-8, and no advantages with the latter.

Notice, it has its own assembler which Iain written, and I can confirm it works perfectly fine.
I have switched my fork to llas by default.

> This guy seems to have made powerpc darwin work in LLVM 8, that's the newest I can find online https://github.com/iains/LLVM-8-Branch Rather use his llvm-7.1.1 (or my port of it for MacPorts). It is better tested than llvm-8, and no advantages with the latter. Notice, it has its own assembler which Iain written, and I can confirm it works perfectly fine. I have switched my fork to `llas` by default.

barracuda156 commented

2025-01-26 06:59:04 -06:00

(Migrated from github.com)

I saw that ppc64 with LLVM 7 doesn't work

Iain’s LLVM 7.1.1 does support ppc64, AFAIK, though personally I only tested using llas for ppc32. I did build his LLVM for ppc64 though, so that works for sure.

Clang is broken for Darwin ppc, do not use it. Until Iain releases his llvm/clang 11.

> I saw that ppc64 with LLVM 7 doesn't work Iain’s LLVM 7.1.1 does support ppc64, AFAIK, though personally I only tested using llas for ppc32. I did build his LLVM for ppc64 though, so that works for sure. Clang is broken for Darwin ppc, do not use it. Until Iain releases his llvm/clang 11.

barracuda156 commented

2025-01-26 07:04:10 -06:00

(Migrated from github.com)

ld64-127 was the last version from Apple to support ppc

It was a regression from ld64-97 though. I would advise avoiding v127, it has bugs, especially for ppc64.

Iain’s darwin-xtools have much newer ld64 with restored ppc/ppc64 support. You may want to try those.

> ld64-127 was the last version from Apple to support ppc It was a regression from ld64-97 though. I would advise avoiding v127, it has bugs, especially for ppc64. Iain’s `darwin-xtools` have much newer ld64 with restored ppc/ppc64 support. You may want to try those.

👀 1

barracuda156 commented

2025-01-26 07:05:52 -06:00

(Migrated from github.com)

@iains @catap Tagging you for clang and cctools.
@Jazzzny @glebm Re cross-compiler.

@iains @catap Tagging you for clang and cctools. @Jazzzny @glebm Re cross-compiler.

Wohlstand commented

2025-01-26 07:59:00 -06:00

(Migrated from github.com)

It was a regression from ld64-97 though. I would advise avoiding v127, it has bugs, especially for ppc64.

Huh, interesting... And I am not sure which version was on my Tiger Mac where I successfully built everything locally with GCC-7. And I attempted to build the cross compiling toolchain, but failed. First attempt resulted semi-working toolchain, but I had or LD crashed on attempt to build with shared links, or produced build was broken, or attempting to build CMake project by that toolchain resulted lots of missing heads and libs even I explicitly pointed the sysroot...

> It was a regression from ld64-97 though. I would advise avoiding v127, it has bugs, especially for ppc64. Huh, interesting... And I am not sure which version was on my Tiger Mac where I successfully built everything locally with GCC-7. And I attempted to build the cross compiling toolchain, but failed. First attempt resulted semi-working toolchain, but I had or LD crashed on attempt to build with shared links, or produced build was broken, or attempting to build CMake project by that toolchain resulted lots of missing heads and libs even I explicitly pointed the sysroot...

barracuda156 commented

2025-01-26 08:28:59 -06:00

(Migrated from github.com)

@Wohlstand I can’t say much about cross-compiling, on that @Jazzzny can respond, perhaps, but natively on Darwin v97 was the best of Apple ones.
Iain has a much newer ld64, which does work on 10.6.8 ppc (and should work on 10.5.8), but I am not sure what its status on 10.4.

@Wohlstand I can’t say much about cross-compiling, on that @Jazzzny can respond, perhaps, but natively on Darwin v97 was the best of Apple ones. Iain has a much newer ld64, which does work on 10.6.8 ppc (and should work on 10.5.8), but I am not sure what its status on 10.4.

👀 2

Jazzzny commented

2025-01-26 11:39:55 -06:00

(Migrated from github.com)

The 10.4u SDK works fine to make a modern GCC and xtools 2.2.0 cross compiling environment (powerpc-apple-darwin8.11.0), though LD needs a patch to comment out a non-fatal "error". In fact, the 10.3 SDK also works to make a powerpc-apple-darwin7.9.0 GCC compiler. With the 10.4 and 10.3 SDKs, GCC can target 10.0 for standard C code (with -lSystemStubs) and 10.3 for C++ code, as thats the minimum that libstdc++ will compile for.

The 10.4u SDK works fine to make a modern GCC and xtools 2.2.0 cross compiling environment (powerpc-apple-darwin8.11.0), though LD needs a patch to comment out a non-fatal "error". In fact, the 10.3 SDK also works to make a powerpc-apple-darwin7.9.0 GCC compiler. With the 10.4 and 10.3 SDKs, GCC can target 10.0 for standard C code (with -lSystemStubs) and 10.3 for C++ code, as thats the minimum that libstdc++ will compile for. <img width="1076" alt="Image" src="https://github.com/user-attachments/assets/94e5c2b0-7af5-4c6c-9a93-271a500cec3a" />

👍 2 👀 1

barracuda156 commented

2025-01-26 13:45:36 -06:00

(Migrated from github.com)

These assume native Darwin, but may still be useful to be tweaked for Linux.

github.com/macos-powerpc/powerpc-ports@ccd819bc18/devel/darwin-xtools (three versions via port variants, optional support for tapi)

github.com/macos-powerpc/powerpc-ports@ccd819bc18/devel/cctools (variants +llvmppc +llas use LLVM 7.1.1)

github.com/macos-powerpc/powerpc-ports@ccd819bc18/devel/ld64 (use either ld64-97 +llvmppc with ld64 +ld64_97, or ld64 +ld64_xtools)

github.com/macos-powerpc/powerpc-ports@ccd819bc18/devel/libtapi (tapi based on LLVM 7.1.1; newer version is moved to libtapi-devel)

github.com/macos-powerpc/powerpc-ports@ccd819bc18/lang/llvm-powerpc (LLVM 7.1.1)

These assume native Darwin, but may still be useful to be tweaked for Linux. https://github.com/macos-powerpc/powerpc-ports/tree/ccd819bc18cb0a3cad6683bb1d2299ac8af9ba1f/devel/darwin-xtools (three versions via port variants, optional support for tapi) https://github.com/macos-powerpc/powerpc-ports/tree/ccd819bc18cb0a3cad6683bb1d2299ac8af9ba1f/devel/cctools (variants +llvmppc +llas use LLVM 7.1.1) https://github.com/macos-powerpc/powerpc-ports/tree/ccd819bc18cb0a3cad6683bb1d2299ac8af9ba1f/devel/ld64 (use either `ld64-97 +llvmppc` with `ld64 +ld64_97`, or `ld64 +ld64_xtools`) https://github.com/macos-powerpc/powerpc-ports/tree/ccd819bc18cb0a3cad6683bb1d2299ac8af9ba1f/devel/libtapi (tapi based on LLVM 7.1.1; newer version is moved to `libtapi-devel`) https://github.com/macos-powerpc/powerpc-ports/tree/ccd819bc18cb0a3cad6683bb1d2299ac8af9ba1f/lang/llvm-powerpc (LLVM 7.1.1)

VariantXYZ commented

2025-01-26 16:32:14 -06:00

(Migrated from github.com)

Thanks @barracuda156 , @Jazzzny . That's a lot of useful information. 10.4.x support seems to be pretty low-priority given its age, so it's difficult to find what works and what doesn't without experimentation...

I was just using llvm 7.1.1 upstream for dsymutil and falling back on @Wohlstand 's forward-ported changes for the remaining cctools with iains' gcc-13 and gcc-14 forks, but it seems like actually testing this on 10.4.11 PPC on qemu, applications throw a Bus Error with EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE. I'll give darwin-xtools a shot and update my Dockerfile accordingly when I get everything working.

Thanks @barracuda156 , @Jazzzny . That's a lot of useful information. 10.4.x support seems to be pretty low-priority given its age, so it's difficult to find what works and what doesn't without experimentation... I was just using llvm 7.1.1 upstream for dsymutil and falling back on @Wohlstand 's forward-ported changes for the remaining cctools with iains' gcc-13 and gcc-14 forks, but it seems like actually testing this on 10.4.11 PPC on qemu, applications throw a Bus Error with EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE. I'll give darwin-xtools a shot and update my Dockerfile accordingly when I get everything working.

barracuda156 commented

2025-01-26 16:45:48 -06:00

(Migrated from github.com)

@VariantXYZ If everything crashes with Bus error, then certainly something is very wrong in the set-up. (Some apps will crash with this because they have bugs in their code, so just getting this with something does not yet mean that toolchain is broken.)

BTW, standard MacPorts’ cctools and ld in their present default variants should work normally on ppc as well (not on ppc64). If xtools linker won’t work in your set-up, revert to ld64-97, it is old, but robust.

@VariantXYZ If everything crashes with Bus error, then certainly something is very wrong in the set-up. (Some apps will crash with this because they have bugs in their code, so just getting this with something does not yet mean that toolchain is broken.) BTW, standard MacPorts’ cctools and ld in their present default variants should work normally on `ppc` as well (not on `ppc64`). If `xtools` linker won’t work in your set-up, revert to `ld64-97`, it is old, but robust.

VariantXYZ commented

2025-01-26 16:57:59 -06:00

(Migrated from github.com)

Sorry if I made it seem like the issue was related to the tools, this is definitely an issue with my setup. I think this is a given, since I'm using a fork of cctools that was mostly created as an experiment and not fully tested.

BTW, standard MacPorts’ cctools and ld in their present default variants should work normally on ppc as well (not on ppc64). If xtools linker won’t work in your set-up, revert to ld64-97, it is old, but robust.

Will give cross-compiling these a shot.

I wonder though, wouldn't the upstream llvm-7.1.1 tools or iains' llvm-7 branch work just as well for a cross-compiled cctools for ppc?

Edit: Woops, never mind, that doesn't include ld.

Sorry if I made it seem like the issue was related to the tools, this is definitely an issue with my setup. I think this is a given, since I'm using a fork of cctools that was mostly created as an experiment and not fully tested. > BTW, standard MacPorts’ cctools and ld in their present default variants should work normally on ppc as well (not on ppc64). If xtools linker won’t work in your set-up, revert to ld64-97, it is old, but robust. Will give cross-compiling these a shot. I wonder though, wouldn't the upstream llvm-7.1.1 tools or iains' llvm-7 branch work just as well for a cross-compiled cctools for ppc? Edit: Woops, never mind, that doesn't include ld.

VariantXYZ commented

2025-01-26 17:36:59 -06:00

(Migrated from github.com)

The 10.4u SDK works fine to make a modern GCC and xtools 2.2.0 cross compiling environment (powerpc-apple-darwin8.11.0), though LD needs a patch to comment out a non-fatal "error". In fact, the 10.3 SDK also works to make a powerpc-apple-darwin7.9.0 GCC compiler. With the 10.4 and 10.3 SDKs, GCC can target 10.0 for standard C code (with -lSystemStubs) and 10.3 for C++ code, as thats the minimum that libstdc++ will compile for.

@Jazzzny , in your example, where did you build ld from? It doesn't seem like darwin-xtools is setup to build for a linux host targeting powerpc-apple-darwin8... or maybe I'm misunderstanding.

> The 10.4u SDK works fine to make a modern GCC and xtools 2.2.0 cross compiling environment (powerpc-apple-darwin8.11.0), though LD needs a patch to comment out a non-fatal "error". In fact, the 10.3 SDK also works to make a powerpc-apple-darwin7.9.0 GCC compiler. With the 10.4 and 10.3 SDKs, GCC can target 10.0 for standard C code (with -lSystemStubs) and 10.3 for C++ code, as thats the minimum that libstdc++ will compile for. > > <img alt="Image" width="1076" src="https://private-user-images.githubusercontent.com/75343012/406751539-94e5c2b0-7af5-4c6c-9a93-271a500cec3a.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzc5MzMxMzcsIm5iZiI6MTczNzkzMjgzNywicGF0aCI6Ii83NTM0MzAxMi80MDY3NTE1MzktOTRlNWMyYjAtN2FmNS00YzZjLTlhOTMtMjcxYTUwMGNlYzNhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAxMjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMTI2VDIzMDcxN1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTE3MjNjYTMwNTFmODg2MDEyNDc3ZGQ3ZDY3OGI3MGJiZTRiZDAwNmEyMjNjY2I1M2ExNDc0ZjUwYjcyNDYzMjMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.dwXGVkqxifnDr9B2dP0z8w0rx7CCSsxbFnRIirVewDk"> @Jazzzny , in your example, where did you build `ld` from? It doesn't seem like darwin-xtools is setup to build for a linux host targeting powerpc-apple-darwin8... or maybe I'm misunderstanding.

Jazzzny commented

2025-01-26 17:43:11 -06:00

(Migrated from github.com)

My apologies - this cross compiler is set up on a macOS 15 ARM64 host. xtools itself doesn't need a special target, and it should be built for the host, but I'm not sure if it is set up to compile on Linux.

Edit: by the way, GCC's libraries (libstdc++, libfortran, etc.) should be compiled with mmacosx-version-min set if you are using an SDK newer than the desired minimum target - otherwise the libraries will build with incorrect assumptions, like symbol and load command availability.

My apologies - this cross compiler is set up on a macOS 15 ARM64 host. xtools itself doesn't need a special target, and it should be built for the host, but I'm not sure if it is set up to compile on Linux. Edit: by the way, GCC's libraries (libstdc++, libfortran, etc.) should be compiled with mmacosx-version-min set if you are using an SDK newer than the desired minimum target - otherwise the libraries will build with incorrect assumptions, like symbol and load command availability.

👀 1

VariantXYZ commented

2025-01-26 17:48:41 -06:00

(Migrated from github.com)

Ah, understood... building on Linux seems to hit a lot of issues with missing headers, but that might be something I can open up a ticket for in the darwin-xtools repo itself after I sanity check a bit more.

Edit: by the way, GCC's libraries (libstdc++, libfortran, etc.) should be compiled with mmacosx-version-min set if you are using an SDK newer than the desired minimum target - otherwise the libraries will build with incorrect assumptions, like symbol and load command availability.

Right, I do configure that flag here: https://github.com/VariantXYZ/gcc-powerpc-apple-darwin8/blob/main/.github/workflows/Dockerfile#L111

Ah, understood... building on Linux seems to hit a lot of issues with missing headers, but that might be something I can open up a ticket for in the darwin-xtools repo itself after I sanity check a bit more. > Edit: by the way, GCC's libraries (libstdc++, libfortran, etc.) should be compiled with mmacosx-version-min set if you are using an SDK newer than the desired minimum target - otherwise the libraries will build with incorrect assumptions, like symbol and load command availability. Right, I do configure that flag here: https://github.com/VariantXYZ/gcc-powerpc-apple-darwin8/blob/main/.github/workflows/Dockerfile#L111

👍 1

Un1q32 commented

2025-01-26 17:50:35 -06:00

(Migrated from github.com)

https://github.com/tpoechtrager/cctools-port/tree/877.8-ld64-253.9-ppc
This is I think the same ld64 version as darwin-xtools, but it runs on Linux. The whole thing doesnt build though, since it tries to build ld_classic and that doesn't work, but you can build just ld64 by running configure and then cd to the ld64 directory and run make, ld will be in cctools/ld64/src/ld/ld.

https://github.com/tpoechtrager/cctools-port/tree/877.8-ld64-253.9-ppc This is I think the same ld64 version as darwin-xtools, but it runs on Linux. The whole thing doesnt build though, since it tries to build ld_classic and that doesn't work, but you can build just ld64 by running configure and then cd to the ld64 directory and run make, ld will be in cctools/ld64/src/ld/ld.

Un1q32 commented

2025-01-26 17:51:49 -06:00

(Migrated from github.com)

I haven't used the old ld-97, I might try later to see if it's more stable.

Un1q32 commented

2025-01-26 17:54:26 -06:00

(Migrated from github.com)

Clang is broken for Darwin ppc, do not use it. Until Iain releases his llvm/clang 11.

I wasn't aware that Iain was working on backporting ppc darwin support to llvm 11, I might wait until that's finished to try the LLVM 20 port, since it would probably save me some work.

> Clang is broken for Darwin ppc, do not use it. Until Iain releases his llvm/clang 11. I wasn't aware that Iain was working on backporting ppc darwin support to llvm 11, I might wait until that's finished to try the LLVM 20 port, since it would probably save me some work.

barracuda156 commented

2025-01-26 17:57:40 -06:00

(Migrated from github.com)

https://github.com/tpoechtrager/cctools-port/tree/877.8-ld64-253.9-ppc This is I think the same ld64 version as darwin-xtools, but it runs on Linux. The whole thing doesnt build though, since it tries to build ld_classic

-DCCTOOLS_LD_CLASSIC=OFF for darwin-xtools build (or a corresponding in makefiles-based build system).

> https://github.com/tpoechtrager/cctools-port/tree/877.8-ld64-253.9-ppc This is I think the same ld64 version as darwin-xtools, but it runs on Linux. The whole thing doesnt build though, since it tries to build ld_classic `-DCCTOOLS_LD_CLASSIC=OFF` for `darwin-xtools` build (or a corresponding in makefiles-based build system).

Un1q32 commented

2025-01-26 18:03:46 -06:00

(Migrated from github.com)

Iain’s LLVM 7.1.1 does support ppc64, AFAIK, though personally I only tested using llas for ppc32. I did build his LLVM for ppc64 though, so that works for sure.

According to that one comment from tpoechtrager upstream only works for simple sources. I haven't tested Iain's forks yet.

> Iain’s LLVM 7.1.1 does support ppc64, AFAIK, though personally I only tested using llas for ppc32. I did build his LLVM for ppc64 though, so that works for sure. According to that one comment from tpoechtrager upstream only works for simple sources. I haven't tested Iain's forks yet.

barracuda156 commented

2025-01-26 18:03:58 -06:00

(Migrated from github.com)

I wasn't aware that Iain was working on backporting ppc darwin support to llvm 11, I might wait until that's finished to try the LLVM 20 port, since it would probably save me some work.

He works on that, but there is no timeline (or at least I am not aware of it). I had an impression that it is not to be expected very soon, though better ask him directly.

> I wasn't aware that Iain was working on backporting ppc darwin support to llvm 11, I might wait until that's finished to try the LLVM 20 port, since it would probably save me some work. He works on that, but there is no timeline (or at least I am not aware of it). I had an impression that it is not to be expected very soon, though better ask him directly.

barracuda156 commented

2025-01-26 18:05:30 -06:00

(Migrated from github.com)

Iain’s LLVM 7.1.1 does support ppc64, AFAIK, though personally I only tested using llas for ppc32. I did build his LLVM for ppc64 though, so that works for sure.

According to that one comment from tpoechtrager upstream only works for simple sources. I haven't tested Iain's forks yet.

Upstream LLVM never generated correct code, AFAIK, even if the thing itself builds.

> > Iain’s LLVM 7.1.1 does support ppc64, AFAIK, though personally I only tested using llas for ppc32. I did build his LLVM for ppc64 though, so that works for sure. > > According to that one comment from tpoechtrager upstream only works for simple sources. I haven't tested Iain's forks yet. Upstream LLVM never generated correct code, AFAIK, even if the thing itself builds.

VariantXYZ commented

2025-01-26 19:15:37 -06:00

(Migrated from github.com)

This is I think the same ld64 version as darwin-xtools, but it runs on Linux. The whole thing doesnt build though, since it tries to build ld_classic and that doesn't work, but you can build just ld64 by running configure and then cd to the ld64 directory and run make, ld will be in cctools/ld64/src/ld/ld.

Interestingly enough, it seems to build fine without any changes:

RUN mkdir -p $ROOT_DIR/cctools-port && \
    cd $ROOT_DIR/cctools-port && \
    git init && \
    git remote add origin https://github.com/tpoechtrager/cctools-port.git && \
    git fetch --depth 1 origin 6694f27d56923e64e6190c8d3eb149413768e9b7 && \
    git checkout FETCH_HEAD && \
    cd cctools && \
    ./autogen.sh

RUN mkdir -p $ROOT_DIR/build/target/cctools-port && \
    cd $ROOT_DIR/build/target/cctools-port && \
    $ROOT_DIR/cctools-port/cctools/configure CC=clang CXX=clang++ --prefix="$TARGET_PREFIX" --target=$TARGET && \
    make -j && \
    make install -j

Though, it seems to not play well with GCC 13.3, since the driver seems to pass it -platform_version and it has no idea how to interpret it:

root@fcaaa8a3c360:/home/csu# make CC=$TARGET_PREFIX/bin/powerpc-apple-darwin8-gcc ARCH_CFLAGS="-arch ppc -D__private_extern__= -isysroot $TARGET_PREFIX/$MAC_SDK_VERSION.sdk --verbose" ./crt1.v1.o          
/usr/local/bin/powerpc-apple-darwin8-gcc -r -arch ppc -D__private_extern__= -isysroot /usr/local/MacOSX10.5.sdk --verbose -Os -mmacosx-version-min=10.4 -mdynamic-no-pic -nostdlib -keep_private_externs start.S crt.c dyld_glue.S -o crt1.v1.o  -DCRT -DOLD_LIBSYSTEM_SUPPORT
Using built-in specs.
COLLECT_GCC=/usr/local/bin/powerpc-apple-darwin8-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/lto-wrapper
Target: powerpc-apple-darwin8
Configured with: /home/gcc/configure CC=clang CXX=clang++ --disable-nls --disable-multilib --enable-languages=c,c++,lto --with-dwarf2 --prefix=/usr/local --target=powerpc-apple-darwin8 --with-sysroot=/usr/local/MacOSX10.5.sdk 'CXXFLAGS_FOR_TARGET=-O2 -g -mmacosx-version-min=10.4' 'CFLAGS_FOR_TARGET=-O2 -g -mmacosx-version-min=10.4' 'LDFLAGS_FOR_TARGET=-O2 -g -mmacosx-version-min=10.4' --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib'  '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4' '-asm_macosx_version_min=10.4' '-nodefaultexport' '-dumpdir' 'crt1.v1.o-'
 /usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/cc1 -E -lang-asm -quiet -v -D__DYNAMIC__ -D __private_extern__= -D CRT -D OLD_LIBSYSTEM_SUPPORT -isysroot /usr/local/MacOSX10.5.sdk start.S -mdynamic-no-pic -m32 -mmacosx-version-min=10.4 -Os -fno-directives-only -o /tmp/ccq7rmcV.s
ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/usr/local/include"
ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/include"
ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include
 /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include-fixed
 /usr/local/MacOSX10.5.sdk/usr/include
 /usr/local/MacOSX10.5.sdk/System/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib'  '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4'  '-nodefaultexport' '-dumpdir' 'crt1.v1.o-'
 /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/bin/as -arch ppc -v -o /tmp/cciYfCoS.o /tmp/ccq7rmcV.s
Apple Inc version cctools-877.8, GNU assembler version 1.38
COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib'  '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4'  '-nodefaultexport' '-dumpdir' 'crt1.v1.o-'
 /usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/cc1 -quiet -v -D__DYNAMIC__ -D __private_extern__= -D CRT -D OLD_LIBSYSTEM_SUPPORT -isysroot /usr/local/MacOSX10.5.sdk crt.c -quiet -dumpdir crt1.v1.o- -dumpbase crt.c -dumpbase-ext .c -mdynamic-no-pic -m32 -mmacosx-version-min=10.4 -Os -version -o /tmp/ccq7rmcV.s
GNU C17 (GCC) version 13.3.0 (powerpc-apple-darwin8)
	compiled by GNU C version Ubuntu Clang 18.1.3 (1ubuntu1), GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/usr/local/include"
ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/include"
ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include
 /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include-fixed
 /usr/local/MacOSX10.5.sdk/usr/include
 /usr/local/MacOSX10.5.sdk/System/Library/Frameworks
End of search list.
Compiler executable checksum: 1f11bed29291879f07497bac4b3e1be5
COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib'  '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4'  '-nodefaultexport' '-dumpdir' 'crt1.v1.o-'
 /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/bin/as -arch ppc -v -o /tmp/ccuuF8WP.o /tmp/ccq7rmcV.s
Apple Inc version cctools-877.8, GNU assembler version 1.38
COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib'  '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4'  '-nodefaultexport' '-dumpdir' 'crt1.v1.o-'
 /usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/cc1 -E -lang-asm -quiet -v -D__DYNAMIC__ -D __private_extern__= -D CRT -D OLD_LIBSYSTEM_SUPPORT -isysroot /usr/local/MacOSX10.5.sdk dyld_glue.S -mdynamic-no-pic -m32 -mmacosx-version-min=10.4 -Os -fno-directives-only -o /tmp/ccq7rmcV.s
ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/usr/local/include"
ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/include"
ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include
 /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include-fixed
 /usr/local/MacOSX10.5.sdk/usr/include
 /usr/local/MacOSX10.5.sdk/System/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib'  '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4'  '-nodefaultexport' '-dumpdir' 'crt1.v1.o-'
 /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/bin/as -arch ppc -v -o /tmp/ccSmNmyf.o /tmp/ccq7rmcV.s
Apple Inc version cctools-877.8, GNU assembler version 1.38
COMPILER_PATH=/usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/:/usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/:/usr/local/libexec/gcc/powerpc-apple-darwin8/:/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/:/usr/local/lib/gcc/powerpc-apple-darwin8/:/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/bin/
LIBRARY_PATH=/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/
COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib'  '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4'  '-nodefaultexport' '-dumpdir' 'crt1.v1.o.'
 /usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/collect2 -demangle -dynamic -arch ppc -syslibroot /usr/local/MacOSX10.5.sdk -platform_version macos 10.4 0.0 -r -o crt1.v1.o -L/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0 /tmp/cciYfCoS.o /tmp/ccuuF8WP.o /tmp/ccSmNmyf.o -keep_private_externs
ld: unknown option: -platform_version
collect2: error: ld returned 1 exit status
make: *** [Makefile:72: crt1.v1.o] Error 1

> This is I think the same ld64 version as darwin-xtools, but it runs on Linux. The whole thing doesnt build though, since it tries to build ld_classic and that doesn't work, but you can build just ld64 by running configure and then cd to the ld64 directory and run make, ld will be in cctools/ld64/src/ld/ld. Interestingly enough, it seems to build fine without any changes: ``` RUN mkdir -p $ROOT_DIR/cctools-port && \ cd $ROOT_DIR/cctools-port && \ git init && \ git remote add origin https://github.com/tpoechtrager/cctools-port.git && \ git fetch --depth 1 origin 6694f27d56923e64e6190c8d3eb149413768e9b7 && \ git checkout FETCH_HEAD && \ cd cctools && \ ./autogen.sh ``` ``` RUN mkdir -p $ROOT_DIR/build/target/cctools-port && \ cd $ROOT_DIR/build/target/cctools-port && \ $ROOT_DIR/cctools-port/cctools/configure CC=clang CXX=clang++ --prefix="$TARGET_PREFIX" --target=$TARGET && \ make -j && \ make install -j ``` Though, it seems to not play well with GCC 13.3, since the driver seems to pass it `-platform_version` and it has no idea how to interpret it: ``` root@fcaaa8a3c360:/home/csu# make CC=$TARGET_PREFIX/bin/powerpc-apple-darwin8-gcc ARCH_CFLAGS="-arch ppc -D__private_extern__= -isysroot $TARGET_PREFIX/$MAC_SDK_VERSION.sdk --verbose" ./crt1.v1.o /usr/local/bin/powerpc-apple-darwin8-gcc -r -arch ppc -D__private_extern__= -isysroot /usr/local/MacOSX10.5.sdk --verbose -Os -mmacosx-version-min=10.4 -mdynamic-no-pic -nostdlib -keep_private_externs start.S crt.c dyld_glue.S -o crt1.v1.o -DCRT -DOLD_LIBSYSTEM_SUPPORT Using built-in specs. COLLECT_GCC=/usr/local/bin/powerpc-apple-darwin8-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/lto-wrapper Target: powerpc-apple-darwin8 Configured with: /home/gcc/configure CC=clang CXX=clang++ --disable-nls --disable-multilib --enable-languages=c,c++,lto --with-dwarf2 --prefix=/usr/local --target=powerpc-apple-darwin8 --with-sysroot=/usr/local/MacOSX10.5.sdk 'CXXFLAGS_FOR_TARGET=-O2 -g -mmacosx-version-min=10.4' 'CFLAGS_FOR_TARGET=-O2 -g -mmacosx-version-min=10.4' 'LDFLAGS_FOR_TARGET=-O2 -g -mmacosx-version-min=10.4' --disable-bootstrap Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.3.0 (GCC) COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib' '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4' '-asm_macosx_version_min=10.4' '-nodefaultexport' '-dumpdir' 'crt1.v1.o-' /usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/cc1 -E -lang-asm -quiet -v -D__DYNAMIC__ -D __private_extern__= -D CRT -D OLD_LIBSYSTEM_SUPPORT -isysroot /usr/local/MacOSX10.5.sdk start.S -mdynamic-no-pic -m32 -mmacosx-version-min=10.4 -Os -fno-directives-only -o /tmp/ccq7rmcV.s ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/usr/local/include" ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/include" ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include-fixed /usr/local/MacOSX10.5.sdk/usr/include /usr/local/MacOSX10.5.sdk/System/Library/Frameworks End of search list. COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib' '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4' '-nodefaultexport' '-dumpdir' 'crt1.v1.o-' /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/bin/as -arch ppc -v -o /tmp/cciYfCoS.o /tmp/ccq7rmcV.s Apple Inc version cctools-877.8, GNU assembler version 1.38 COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib' '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4' '-nodefaultexport' '-dumpdir' 'crt1.v1.o-' /usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/cc1 -quiet -v -D__DYNAMIC__ -D __private_extern__= -D CRT -D OLD_LIBSYSTEM_SUPPORT -isysroot /usr/local/MacOSX10.5.sdk crt.c -quiet -dumpdir crt1.v1.o- -dumpbase crt.c -dumpbase-ext .c -mdynamic-no-pic -m32 -mmacosx-version-min=10.4 -Os -version -o /tmp/ccq7rmcV.s GNU C17 (GCC) version 13.3.0 (powerpc-apple-darwin8) compiled by GNU C version Ubuntu Clang 18.1.3 (1ubuntu1), GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/usr/local/include" ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/include" ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include-fixed /usr/local/MacOSX10.5.sdk/usr/include /usr/local/MacOSX10.5.sdk/System/Library/Frameworks End of search list. Compiler executable checksum: 1f11bed29291879f07497bac4b3e1be5 COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib' '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4' '-nodefaultexport' '-dumpdir' 'crt1.v1.o-' /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/bin/as -arch ppc -v -o /tmp/ccuuF8WP.o /tmp/ccq7rmcV.s Apple Inc version cctools-877.8, GNU assembler version 1.38 COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib' '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4' '-nodefaultexport' '-dumpdir' 'crt1.v1.o-' /usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/cc1 -E -lang-asm -quiet -v -D__DYNAMIC__ -D __private_extern__= -D CRT -D OLD_LIBSYSTEM_SUPPORT -isysroot /usr/local/MacOSX10.5.sdk dyld_glue.S -mdynamic-no-pic -m32 -mmacosx-version-min=10.4 -Os -fno-directives-only -o /tmp/ccq7rmcV.s ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/usr/local/include" ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/include" ignoring nonexistent directory "/usr/local/MacOSX10.5.sdk/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/include-fixed /usr/local/MacOSX10.5.sdk/usr/include /usr/local/MacOSX10.5.sdk/System/Library/Frameworks End of search list. COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib' '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4' '-nodefaultexport' '-dumpdir' 'crt1.v1.o-' /usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/bin/as -arch ppc -v -o /tmp/ccSmNmyf.o /tmp/ccq7rmcV.s Apple Inc version cctools-877.8, GNU assembler version 1.38 COMPILER_PATH=/usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/:/usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/:/usr/local/libexec/gcc/powerpc-apple-darwin8/:/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/:/usr/local/lib/gcc/powerpc-apple-darwin8/:/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/../../../../powerpc-apple-darwin8/bin/ LIBRARY_PATH=/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0/ COLLECT_GCC_OPTIONS='-r' '-D' '__private_extern__=' '-isysroot' '/usr/local/MacOSX10.5.sdk' '-v' '-Os' '-mdynamic-no-pic' '-nostdlib' '-o' 'crt1.v1.o' '-D' 'CRT' '-D' 'OLD_LIBSYSTEM_SUPPORT' '-m32' '-mmacosx-version-min=10.4' '-nodefaultexport' '-dumpdir' 'crt1.v1.o.' /usr/local/libexec/gcc/powerpc-apple-darwin8/13.3.0/collect2 -demangle -dynamic -arch ppc -syslibroot /usr/local/MacOSX10.5.sdk -platform_version macos 10.4 0.0 -r -o crt1.v1.o -L/usr/local/lib/gcc/powerpc-apple-darwin8/13.3.0 /tmp/cciYfCoS.o /tmp/ccuuF8WP.o /tmp/ccSmNmyf.o -keep_private_externs ld: unknown option: -platform_version collect2: error: ld returned 1 exit status make: *** [Makefile:72: crt1.v1.o] Error 1 ```

Un1q32 commented

2025-01-26 19:26:41 -06:00

(Migrated from github.com)

Though, it seems to not play well with GCC 13.3, since the driver seems to pass it -platform_version and it has no idea how to interpret it

Clang has a command line argument -mlinker-version=253.9, try that with GCC.

> Though, it seems to not play well with GCC 13.3, since the driver seems to pass it -platform_version and it has no idea how to interpret it Clang has a command line argument `-mlinker-version=253.9`, try that with GCC.

👀 1

Jazzzny commented

2025-01-26 19:27:33 -06:00

(Migrated from github.com)

You need to delete a few lines from GCC's configure script by following https://github.com/macos-powerpc/macos-powerpc-cross-compiler/blob/main/patches/gcc-patch-configure.patch

This is because GCC seemingly assumes that these are available based on the linker that was used to link GCC, rather than the specified linker.

You need to delete a few lines from GCC's configure script by following https://github.com/macos-powerpc/macos-powerpc-cross-compiler/blob/main/patches/gcc-patch-configure.patch This is because GCC seemingly assumes that these are available based on the linker that was used to link GCC, rather than the specified linker.

👍 1

VariantXYZ commented

2025-01-26 19:53:23 -06:00

(Migrated from github.com)

Clang has a command line argument -mlinker-version=253.9, try that with GCC.

No such luck.

You need to delete a few lines from GCC's configure script by following

Will try this. As an aside, it should just be possible to forcibly override these with CONFIG_SITE, I think?

> Clang has a command line argument -mlinker-version=253.9, try that with GCC. No such luck. > You need to delete a few lines from GCC's configure script by following Will try this. As an aside, it should just be possible to forcibly override these with CONFIG_SITE, I think?

VariantXYZ commented

2025-01-27 00:46:58 -06:00

(Migrated from github.com)

Horray, it seems to all work. Here's GCC13.3 + SDK 10.4u: https://github.com/VariantXYZ/gcc-powerpc-apple-darwin8/blob/build/gcc-13.3%2BMacOSXSDK10.4u/.github/workflows/Dockerfile

The rgbds toolchain seems to work with that, I'm testing cpython 3.12 against GCC14.2 + 10.5 now.

Horray, it seems to all work. Here's GCC13.3 + SDK 10.4u: https://github.com/VariantXYZ/gcc-powerpc-apple-darwin8/blob/build/gcc-13.3%2BMacOSXSDK10.4u/.github/workflows/Dockerfile The rgbds toolchain seems to work with that, I'm testing cpython 3.12 against GCC14.2 + 10.5 now.

👍 1 🎉 1

barracuda156 commented

2025-01-27 01:44:32 -06:00

(Migrated from github.com)

Now someone should make a cross-compiler from macOS PowerPC to Linux RISC-V :)

P. S. I could actually even use it sensibly, since PineTab-V is pretty slow, and at least in some cases G5 will be faster.

Now someone should make a cross-compiler from macOS PowerPC to Linux RISC-V :) P. S. I could actually even use it sensibly, since PineTab-V is pretty slow, and at least in some cases G5 will be faster.

😆 1

VariantXYZ commented

2025-01-27 02:38:02 -06:00

(Migrated from github.com)

I'm testing cpython 3.12 against GCC14.2 + 10.5 now.

Well, it builds and doesn't immediately bus error, so that's a start. It's failing due to expecting some things that just aren't in the 10.4 SDK, but this is sufficient for now to verify things can build and seemingly run correctly, at least.

> I'm testing cpython 3.12 against GCC14.2 + 10.5 now. Well, it builds and doesn't immediately bus error, so that's a start. It's failing due to expecting some things that just aren't in the 10.4 SDK, but this is sufficient for now to verify things can build and seemingly run correctly, at least.

Un1q32 commented

2025-01-27 06:49:21 -06:00

(Migrated from github.com)

Now someone should make a cross-compiler from macOS PowerPC to Linux RISC-V :)

Macports has gcc 14 builds for ppc so you could probably modify those to cross compile to riscv linux

> Now someone should make a cross-compiler from macOS PowerPC to Linux RISC-V :) Macports has gcc 14 builds for ppc so you could probably modify those to cross compile to riscv linux

barracuda156 commented

2025-01-27 06:55:32 -06:00

(Migrated from github.com)

@Un1q32 Given that I had the current gcc (from gcc11 every version onwards, currently incl. gcc15) on powerpc via MacPorts two years before MacPorts upstream finally did that, I know :)

😆 1

Un1q32 commented

2025-01-27 09:53:52 -06:00

(Migrated from github.com)

LLVM 20 branch is scheduled to be created tomorrow IIRC, I have school stuff so I won't be able to do much right away, in the mean time can someone tell me where I can get source code for ld-97.

barracuda156 commented

2025-01-27 09:58:00 -06:00

(Migrated from github.com)

where I can get source code for ld-97.

Original: https://github.com/apple-oss-distributions/ld64/tree/ld64-97.17

Patches: https://github.com/macports/macports-ports/tree/master/devel/ld64

> where I can get source code for ld-97. Original: https://github.com/apple-oss-distributions/ld64/tree/ld64-97.17 Patches: https://github.com/macports/macports-ports/tree/master/devel/ld64

❤️ 1

Un1q32 commented

2025-01-27 10:05:22 -06:00

(Migrated from github.com)

No linux port? I guess I'll make it myself

barracuda156 commented

2025-01-27 11:11:27 -06:00

(Migrated from github.com)

No linux port? I guess I'll make it myself

I am not sure it is needed. Usually whatever important (for development, at least) from MacPorts does not build from default portfiles on Linux, it is found fixed here: https://github.com/RJVB/lnxports

@RJVB will know better. My exposure to Linux is extremely limited.

> No linux port? I guess I'll make it myself I am not sure it is needed. Usually whatever important (for development, at least) from MacPorts does not build from default portfiles on Linux, it is found fixed here: https://github.com/RJVB/lnxports @RJVB will know better. My exposure to Linux is extremely limited.

RJVB commented

2025-01-27 11:28:29 -06:00

(Migrated from github.com)

The project claims to support Linux, but not why. Cross-building would be the only reason I can see.

My lnxports repo basically only contains ports for which I have or had a need and that were too complex and/or different from the Mac implementation to make a single multi-platform port, or simply cannot be supported on Mac.

The project claims to support Linux, but not why. Cross-building would be the only reason I can see. My `lnxports` repo basically only contains ports for which I have or had a need and that were too complex and/or different from the Mac implementation to make a single multi-platform port, or simply cannot be supported on Mac.

Un1q32 commented

2025-01-27 11:52:50 -06:00

(Migrated from github.com)

Yes I intend to cross build, I have a whole repo of build scripts for modern unix software that builds for iOS 3, OSX 10.6 for x86, and hopefully soon OSX 10.5 for PowerPC.

👍 2

Un1q32 commented

2025-01-30 10:46:58 -06:00

(Migrated from github.com)

I tried diffing iains llvm 8 repo with upstream and merging the changes into llvm 20, but there seems to be a lot of powerpc darwin stuff that hadn't been removed by llvm 8 but was removed since, so I'll probobly wait for the llvm 11 release from iains or maybe try to step up versions one at a time (get it working in llvm 9, then 10, etc).

barracuda156 commented

2025-01-30 11:24:07 -06:00

(Migrated from github.com)

@Un1q32 It is probably not hard to find commits removing Darwin support:

https://reviews.llvm.org/D75494

https://reviews.llvm.org/D146459

https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20200120/732917.html

Or perhaps pick LLVM prior to that being removed.

P. S. Would be cool to convince upstream to restore it, but we have to do the work, if they agree.

@Un1q32 It is probably not hard to find commits removing Darwin support: https://reviews.llvm.org/D75494 https://reviews.llvm.org/D146459 https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20200120/732917.html Or perhaps pick LLVM prior to that being removed. P. S. Would be cool to convince upstream to restore it, but we have to do the work, if they agree.

iains commented

2025-01-30 11:50:49 -06:00

(Migrated from github.com)

there's more needed than just bringing the patches forward (although that should work as far as the MC layer is concerned - so to provide the assembler etc.). It is better to go one patch at a time and make sure you understand what the patch is supposed to do and that it still works when applied to the later version.
re-instating powerpc-darwin upstream has two large obstacles (which is why it was removed in the first place)
2a) they want a guarantee that someone works actively on it to fix problems (which is fine if it's $dayjob but not viable for $hobby)
2b) they want a usable build-bot .. which is extremely hard to arrange given how little hardware is available and how slow it is.

even with the LLVM-11 version (which is more complete than the 7/8 editions) there is still more to do -- however, I'll try and find some time to tidy up the WIP enough to push it

1. there's more needed than just bringing the patches forward (although that should work as far as the MC layer is concerned - so to provide the assembler etc.). It is better to go one patch at a time and make sure you understand what the patch is supposed to do and that it still works when applied to the later version. 2. re-instating powerpc-darwin upstream has two large obstacles (which is why it was removed in the first place) 2a) they want a guarantee that someone works actively on it to fix problems (which is fine if it's $dayjob but not viable for $hobby) 2b) they want a usable build-bot .. which is extremely hard to arrange given how little hardware is available and how slow it is. 3) even with the LLVM-11 version (which is more complete than the 7/8 editions) there is still more to do -- however, I'll try and find some time to tidy up the WIP enough to push it

👍 2 🎉 1

VariantXYZ commented

2025-01-30 17:11:22 -06:00

(Migrated from github.com)

Given the discussions on cross-compilation that've been happening:

2b) they want a usable build-bot .. which is extremely hard to arrange given how little hardware is available and how slow

Regarding this, the issue is primarily testing right? This could be a "target, but not host" scenario where the toolchain is built on a linux host and testing could be done against a QEMU implementation of the device, maybe? Or is this an unacceptable solution to this obstacle?

Of course, the maintenance task is undoubtedly the bigger hurdle...

Given the discussions on cross-compilation that've been happening: > 2b) they want a usable build-bot .. which is extremely hard to arrange given how little hardware is available and how slow Regarding this, the issue is primarily testing right? This could be a "target, but not host" scenario where the toolchain is built on a linux host and testing could be done against a QEMU implementation of the device, maybe? Or is this an unacceptable solution to this obstacle? Of course, the maintenance task is undoubtedly the bigger hurdle...

Wohlstand commented

2025-01-30 17:14:34 -06:00

(Migrated from github.com)

On my end, I have real hardware, the Mac Mini G4, and so, I want to debug on it easier. Development on itself is not so comfortable because of long build (just one single core CPU and low tact frequency, my project that builds on my main PC in 2-3 minutes, on Mac Mini the complete build takes half of hour 👀)

On my end, I have real hardware, the Mac Mini G4, and so, I want to debug on it easier. Development on itself is not so comfortable because of long build (just one single core CPU and low tact frequency, my project that builds on my main PC in 2-3 minutes, on Mac Mini the complete build takes half of hour :eyes:)

Un1q32 commented

2025-01-30 17:54:41 -06:00

(Migrated from github.com)

If for some reason we're required to run a toolchain on-device my previously mentioned repo of cross build scripts has ones for libc++, llvm, and clang (all latest versions), so you won't have to wait multiple days to get a toolchain built.
I plan to eventually provide prebuilt binaries for OSX (currently only iOS has them) and maybe even automate builds somehow.

If for some reason we're required to run a toolchain on-device my previously mentioned repo of cross build scripts has ones for libc++, llvm, and clang (all latest versions), so you won't have to wait multiple days to get a toolchain built. I plan to eventually provide prebuilt binaries for OSX (currently only iOS has them) and maybe even automate builds somehow.

barracuda156 commented

2025-01-30 18:25:14 -06:00

(Migrated from github.com)

there's more needed than just bringing the patches forward (although that should work as far as the MC layer is concerned - so to provide the assembler etc.).

@iains Yeah, forward-porting patches did not work for libc++[abi] (from 7.x to 11.x) for me. I did not have time to look into the issue yet (so maybe it is something totally trivial), but looks like changes since 7.x were significant.

re-instating powerpc-darwin upstream has two large obstacles (which is why it was removed in the first place)
2a) they want a guarantee that someone works actively on it to fix problems (which is fine if it's $dayjob but not viable for $hobby)

Darwin ppc doesn’t change much (maximum what might happen is restoring ppc64 into 10.6), so once it is fixed once, it probably will not require constant fix-ups. At what rate the upstream wants to break things, after all.

2b) they want a usable build-bot .. which is extremely hard to arrange given how little hardware is available and how slow it is.

Shouldn’t 10.5 or/and 10.6 with Rosetta work for that? On a reasonably fast Intel machine Rosetta works decently (and something like MacMini suffices). And perhaps it is not necessary to run the builds per-commit.

even with the LLVM-11 version (which is more complete than the 7/8 editions) there is still more to do -- however, I'll try and find some time to tidy up the WIP enough to push it

This would be awesome.

I can work on some components then (not codegen but something less esoteric), and maybe Kirill @catap extends his fixes for compiler-rt to PowerPC (on which I can work together with him).

> 1. there's more needed than just bringing the patches forward (although that should work as far as the MC layer is concerned - so to provide the assembler etc.). @iains Yeah, forward-porting patches did not work for `libc++[abi]` (from 7.x to 11.x) for me. I did not have time to look into the issue yet (so maybe it is something totally trivial), but looks like changes since 7.x were significant. > 2. re-instating powerpc-darwin upstream has two large obstacles (which is why it was removed in the first place) > 2a) they want a guarantee that someone works actively on it to fix problems (which is fine if it's $dayjob but not viable for $hobby) Darwin ppc doesn’t change much (maximum what might happen is restoring ppc64 into 10.6), so once it is fixed once, it probably will not require constant fix-ups. At what rate the upstream wants to break things, after all. > 2b) they want a usable build-bot .. which is extremely hard to arrange given how little hardware is available and how slow it is. Shouldn’t 10.5 or/and 10.6 with Rosetta work for that? On a reasonably fast Intel machine Rosetta works decently (and something like MacMini suffices). And perhaps it is not necessary to run the builds per-commit. > 3) even with the LLVM-11 version (which is more complete than the 7/8 editions) there is still more to do -- however, I'll try and find some time to tidy up the WIP enough to push it This would be awesome. I can work on some components then (not codegen but something less esoteric), and maybe Kirill @catap extends his fixes for `compiler-rt` to PowerPC (on which I can work together with him).

Rows
Columns

[bug] ld doesn't support ppc #119