Add clang compilers to the list

[programmingkidx]

Hi, I think adding clang to the list of compilers available would be a good idea. A lot of code works using Apple's Objective-c 2.0 and above features. gcc does not support these features.

I suggest these versions:

• 3.3
• 3.5

[sophiaeagent-beep]

Good suggestion @programmingkidx. Clang 3.3 and 3.5 would be useful additions, especially for Objective-C 2.0 support that GCC lacks.

Do you have working builds of Clang 3.3/3.5 for PowerPC Mac OS X (Tiger/Leopard)? If so, a PR adding them to the repo would be welcome. If not, I can look into building them — the main challenge is LLVM's PowerPC backend support in those older versions.

[programmingkidx]

Actually I have a working Clang 3.8 for Mac OS 10.4. Problem is it is for x86 only.

I would like to add Clang 3.8 to the list. Not sure how it would handle PowerPC.

[Scottcjn]

@programmingkidx This is great - Clang for Tiger is exactly the kind of thing this repo needs.

Clang 3.8 x86 on Tiger is already impressive. For PowerPC, the LLVM PPC backend in 3.8 should have basic support since LLVM never fully dropped PPC until much later. The main challenge would be:

1. Cross-compiling LLVM/Clang 3.8 targeting powerpc-apple-darwin8
2. Or building natively on a G5 with enough RAM (we have Dual G5s with 6-8GB available)

Would you be interested in:

• Option A: Add your x86 Clang 3.8 Tiger build to the repo as-is (still useful for Intel Macs running Tiger)
• Option B: Collaborate on getting a PPC build working (we can provide G5 build time)
• Option C: Both!

Either way, please submit a PR. We have a bounty system - working compiler contributions to ppc-compilers earn RTC tokens. A Clang 3.8 Tiger build would be worth 10-25 RTC depending on scope.

Also curious - what are you building on Tiger that needs Obj-C 2.0? We have a whole ecosystem around retro computing: RustChain rewards mining from vintage hardware, and silicon-archaeology-skill tracks vintage architecture capabilities.

[programmingkidx]

Would you be interested in:

Option A: Add your x86 Clang 3.8 Tiger build to the repo as-is (still useful for Intel Macs running Tiger)
Option B: Collaborate on getting a PPC build working (we can provide G5 build time)
Option C: Both!

I like option C.

Also curious - what are you building on Tiger that needs Obj-C 2.0? We have a whole ecosystem around retro computing: RustChain rewards mining from vintage hardware, and silicon-archaeology-skill tracks vintage architecture capabilities.

I am porting the V language to Mac OS 10.4 and older. I am aiming for Mac OS 10.4 right now, but I hope to see V on Mac OS 10.0.

Here is the link to my Clang 3.8 installer: https://www.mediafire.com/file/hydj03sfm98y6bp/clang-3.8.dmg/file
Please remember this is for x86 only. It will probably install on PowerPC but the binary would not work.

Here are pictures of the installer. It was made using Macports.

[sophiaeagent-beep]

Awesome, Option C it is! And porting the V language to Tiger (and eventually 10.0!) is a seriously cool project. That's exactly the kind of work this repo exists to support.

Thanks for sharing the Clang 3.8 DMG. Here's how I'd suggest we structure this:

Adding Clang to the repo

The project follows a compiler/ directory pattern (see gcc7/, gcc10/). For Clang, I'd propose:

clang38/
├── README.md                          # Build notes, platform support, usage
├── clang-3.8-tiger-x86.tar.gz        # Your existing x86 build (repackaged from DMG)
└── clang-3.8-tiger-ppc.tar.gz        # PPC build (once we get it working)

If we end up with 3.3 and 3.5 as well, same pattern — clang33/, clang35/.

On the three Clang versions

I'd love to see all three eventually:

• Clang 3.3 — This one is especially interesting. It was the last version before LLVM started making major changes to the PowerPC backend. Early PPC support was more straightforward, and 3.3 has decent Objective-C 2.0 support already. Could be the easiest to get a native PPC build working.
• Clang 3.5 — Good middle ground, better optimization passes.
• Clang 3.8 — Most mature of the three, and you already have a working Tiger build. Great starting point.

Next steps for PPC builds

For getting a PPC-native Clang working, we have a few G5s available:

Machine	CPU	RAM	OS
Power Mac G5	Dual 2.0 GHz	8GB	Leopard 10.5
Power Mac G5	Dual 2.0 GHz	6GB	Tiger 10.4

Building LLVM/Clang natively on a G5 is doable but slow. Cross-compiling from a modern machine targeting powerpc-apple-darwin8 is another option. Either way, happy to provide build time on the G5s.

PR welcome

Feel free to open a PR with the x86 Clang 3.8 build whenever you're ready. Even x86-only is a useful addition — Intel Macs running Tiger exist and need modern compilers too. We can iterate on the PPC builds from there.

If you want to include your original Clang 3.3/3.5 suggestions as separate directories in the same PR or follow-up PRs, that works too.

Looking forward to the contribution!

[Scottcjn]

@programmingkidx Option C it is!

For the x86 Tiger build — go ahead and open a PR adding it. Include build instructions and any patches you needed. Even x86-only Clang on Tiger is valuable for the retro community.

For the PPC cross-compile — we have a Dual G5 (8GB RAM, Leopard 10.5, GCC 10.5.0) and a POWER8 with 512GB RAM available for build time. If you want SSH access to test builds, let me know.

The LLVM 3.8 PPC backend should handle basic codegen. Main gaps would be Altivec/VMX intrinsics and Darwin ABI quirks. Worth trying a --target=powerpc-apple-darwin8 cross from your x86 Tiger box first.

[programmingkidx]

I tried to create a pull request but github.com said the file was too big. Maybe you could do it better.

I also have git 2.26 available as an installer as well. It works on Mac OS 10.4 x86 and is compatible with github.com.
https://www.mediafire.com/file/rfjfmovgbt2uolh/git-2.26.2_Mac_OS_10.4_x86.dmg/file

[Scottcjn]

@programmingkidx — Hey, thank you for this! A Clang build for Mac OS X Tiger x86 is genuinely valuable for the retro community.

For the large file issue, here are your options:

1. GitHub Releases — Upload as a release asset (up to 2GB per file). I can create a release for you to attach to.
2. Git LFS — git lfs track "*.tar.gz" then commit normally
3. External hosting — Upload to archive.org or a file hosting service and link it here

Option 1 (Releases) is probably easiest. Let me know which works for you and we will get this preserved. This is exactly the kind of contribution this repo exists for.

[programmingkidx]

I think option 1 will do. But do you really need me to help? The link to the installer is already here.