what is the proper way to build this?

[donbright]

I have been playing around with llvm on osx 10.5 Powerpc but one thing that has puzzled me is the "proper" way to build llvm and its assorted helpers.

the standard llvm github checkout comes with everything underneath llvm-project, and apparently i am supposed to use the single CMakeLists from that project to build everything, clang, included, from a build directory.

but the releases of llvm (tarballs) come with each sub project in a side directory... llvm , clang, etc. i have been able to build basic pieces of llvm like this, but i am still wondering, what is the proper order in which to compile clang, lld, compiler-rt, polly, etc etc? how can they be told where llvm lives ( i presume llvm is to be built first?) ?

and of course on 10.5.8 Powerpc , what is the best way to get the minimum versions of tools required? i know there is Mac Ports but is there a list of which ports to install?

currently i am attempting with my own custom built non-ports versions of cmake, gcc 6, zlib, etc, but i am not sure if they are high enough (until i wait a few hours and see if the build fails?).

thank you

[kencu]

I think you will find there has been a lot of effort put into the toolchains on MacPorts that you can leverage. certainly cmake, gcc-4.x, gcc-5, gcc-6, and gcc-7 work great there. cctools is quite current, and a recent ld64-127 is working on PPC (although I would like to bring it up to something newer with iains ld64 patches here).

I have built clang-5.0 for PowerPC on MacPorts, and it is self-consistent. Iain's clang/llvm-7.0 is on my to-do list next, and adding in his llas tool would be very helpful.

I don't believe there is a larger or more knowledgable collection of darwin powerpc users anywhere besides MacPorts; certainly for ongoing toolchain and software support, that is the only real game in town.

[iains]

• These comments relate to powerpc-darwin9, the Intel version is much more complete (albeit there are probably some issues with stubs and/or use of partitioning)

1. the branch here is quite complete w.r.t support for the LLVM MC layer etc (so it works to make a reliable assembler and dsymutil - which are needed for more modern projects).
2. The clang is more complete than upstream - but it is still not fully compliant with the ABI as set by the system GCC-4.0 (it is useable for 32b)
3. The compiler-rt needs more work to be useful
4. Likewise libc++
5. layout of the sources - this branch is laid out "the old way" (from SVN days). In that case the sources for each of the trees were checked out in the same place - then one can build a composite tree (i.e. like the git mono-repo) by symlinking them into place . .... so llvm/tools/clang -> ../../clang llvm/projects/compiler-rt -> ../../compiler-rt etc. etc.

I also symlink tapi into clang/tools/

So .. the answer depends on what you want to achieve.

a) the purpose I have it here is to provide a modern assembler ('llas'), dsymutil, libLTO.dylib and tapi to support newer toolchains.

b) One can build a stand-alone clang that is self-consistent (and maybe there are patches for compiler-rt and libc++ that will enable it to build). However, whether it will interoperate reliably with the system compiler is doubtful.

Of course, I am building this with GCC - and using at least GCC5.3 (since we need a c++11 compiler)

====

As for GCC - all versions up to and including current master (GCC-12) bootstrap and work well and are tested quite regularly on powerpc-darwin9. Actually, a couple of long-standing critical bugs were fixed in the recent 10.3 release - so until those are back ported (they will be in gcc-9.4. when that is released) I'd suggest 10.3 or 11.1 would be better than the older releases (hopefully, we will eventually get time to back port the main fixes all the way to gcc-5 so that people using Java can have them).

Sorry I don't have any free time at present to progress these things ..

[kencu]

I think if I can put together a working set of Portfiles that build this for the "common user", the "market penetration" will become much more widespread. There is demand weekly if not daily for this on the MP mailing lists.

And then perhaps we can get that last ABI bit over the threshold, and have a fully working setup, once people are using this.

[donbright]

thanks