llvm dev - Oct 2021 - PowerPC LLVM support much appreciated

Hello Iain,

Recently I decided to set myself the entirely alien task of getting Rust 
to work on PowerPC Darwin (10.4/10.5). I mostly program in Python/Go and 
am a newbie to Rust. Nevertheless, I've done some research and asked 
around on LLVM discord and was told to direct my questions to you.

Being new to compiler/assembler development, could you fill me in on the 
scope of this task I've just set myself?

The instructions here 
https://github.com/iains/darwin-toolchains-start-here seem incomplete, 
and for someone who doesn't know much about compiler development like 
me, I think it's missing quite a bit of context. Does it work, would I 
get a LLVM which I could use to compile LLVM IR generated by rustc?

Looking at the LLVM changelog, I have the impression that LLVM's major 
versions don't change that much, so later versions of LLVM shouldn't be 
too hard to get working either, am I correct?

What other roadblocks do you foresee? I was under the impression that I 
only need to get LLVM to emit PowerPC MachO, but since then I have also 
heard that I need to get Rust to work with 10.4/10.5's libc... which 
means both language and compiling backend need to have access to the 
10.4/10.5 libraries... which means I shouldn't try to setup a cross 
compiler with my current state of knowledge. More clarification/context 
much appreciated.


Kind regards,

Andrew Chiw

Hi,

Darwin support in PowerPC backend was deprecated in LLVM 8.0.0
(https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html) and some was removed in
later releases. So you need an earlier LLVM version to generate code on Darwin
PowerPC, which may not be fully compatible with latest rustc.

Regards,
> Andrew Chiw via llvm-dev <llvm-dev at lists.llvm.org> wrote at
2021/10/21 5:01 AM:
> 
> Hello Iain,
> 
> Recently I decided to set myself the entirely alien task of getting Rust to
work on PowerPC Darwin (10.4/10.5). I mostly program in Python/Go and am a
newbie to Rust. Nevertheless, I've done some research and asked around on
LLVM discord and was told to direct my questions to you.
> 
> Being new to compiler/assembler development, could you fill me in on the
scope of this task I've just set myself?
> 
> The instructions here https://github.com/iains/darwin-toolchains-start-here
seem incomplete, and for someone who doesn't know much about compiler
development like me, I think it's missing quite a bit of context. Does it
work, would I get a LLVM which I could use to compile LLVM IR generated by
rustc?
> 
> Looking at the LLVM changelog, I have the impression that LLVM's major
versions don't change that much, so later versions of LLVM shouldn't be
too hard to get working either, am I correct?
> 
> What other roadblocks do you foresee? I was under the impression that I
only need to get LLVM to emit PowerPC MachO, but since then I have also heard
that I need to get Rust to work with 10.4/10.5's libc... which means both
language and compiling backend need to have access to the 10.4/10.5 libraries...
which means I shouldn't try to setup a cross compiler with my current state
of knowledge. More clarification/context much appreciated.
> 
> 
> Kind regards,
> 
> Andrew Chiw
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Fri, Oct 22, 2021 at 3:52 AM Andrew Chiw via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> [...]
>
> What other roadblocks do you foresee? I was under the impression that I
> only need to get LLVM to emit PowerPC MachO, but since then I have also
> heard that I need to get Rust to work with 10.4/10.5's libc... which
> means both language and compiling backend need to have access to the
> 10.4/10.5 libraries... which means I shouldn't try to setup a cross
> compiler with my current state of knowledge. More clarification/context
> much appreciated.
There was a time, far before LLVM was started, when conservative use
of UNIX system libraries was a must in every robust project, so that
you never used "cutting edge" APIs, but just POSIX standard headers.

Unfortunately, the current trend in development is totally opposite to
that. Now, people always use cutting-edge headers, cutting-edge
compilers, cutting-edge language versions (now the trend is that
nothing is cooler than increasing the C++ version required to build
your code). They justify it by saying nobody should use old OSs
because of security, but that's not the real truth (disconnect the
net, and you'll have far more security than the most modern OS). The
real truth, however, is that by requiring the latest cutting-edge
APIs, people buy newer hardware (which let's admit it: it's cool to
unbox a brand-new computer, so few people get angry at that), a new
hardware which by the way is not able to run older OSs, which in turn
gives the (false) impression that the decision to drop support for
older OSs was right. And the wheel goes on and on like that, until
arriving to a point where people accuse you of causing harm to
humankind by using older OSs.

It's a fact that the most modern compiler, linker, and debugger
doesn't strictly need any service not included in POSIX. Extra
requirements are thus artificial, created by the wheel of the trends.
Unfortunately, that's how it  works nowadays.

Then, even if you managed to get a 100-people team developing a new
compiler toolchain that required only POSIX, you'll soon face new
problems, because when you'll try to build software with your good
compiler, you'll realize that most applications out there not only
require C++50 to be built, but also new vendor-dependent APIs not
available in your machine).

That's how it works now.

Ardi