[vvuk]

I could build you a tardist of this likely -- it's not a big deal and would allow easier install/uninstall for users who aren't using RSE (Such as myself)

What work remains to be done as far as getting multilib support fixed? What kind of C++ projects are working?

Any "gotchas" we should know about?

Full 64-bit ABI doesn't really work; the codegen has bugs. It's not super well supported by upstream though it's something I'd like to get working at some point. Other than that nothing that I'm aware of but I'm sure there will be lots of issues especially in various threading/TLS areas. At some point I'm going to get the actual test suite going.

If you can, it'd be also great if we could get a full "bootstrap" env we could use to build LLVM outside of using any external tools. I know that's a tall order, and I'm not expecting you to offer it necessarily. But failing that, a list of what we need to build LLVM on IRIX, patches against a stable version, and general "procedure" would be fabulous. I am interested in building a wiki article on this after all. It would also be nice to know how you built your Linux xcomp env.

You just need LLVM to bootstrap. After that there's a variety of scripts (in various shapes of working) inside the `irix` dir in the repo tree, including a `build-all.sh` script that will do a full cross & native build on linux. All it needs is an irix root in `/opt/irix/root` to build against; that can get copied from a working machine, or set up using the ruby inst script that the qemu-irix folks have. When building under IRIX some cmake tweaks will likely be needed since you're not longer cross compiling, but the setup-irix-native.sh script would be a good place to start.

Comments on the tardist packaging:

I understand that you're limited on time and everything. But /usr/sgug for a tarball is problematic. It's another include path, for instance.

I'd suggest /usr/llvm or something if you're offering an independent distribution, or for nekoware users, /usr/nekoware/llvm.

I'm willing to do this I just need ot know what the heck is actually needed to bootstrap.

It's no different than /usr/llvm in that respect. But llvm is largely location independent, so it can be moved wherever. If you're building something with clang anyway, chances are you want a reasonably modern environment; SGUG is really the only place where that's happening. Otherwise the MIPSpro compilers are going to be a better bet anyway.

[Raion]

I mean, me and others are working on something. The reason that we've not released it is because I haven't received authorization to do so.

Regardless, I do have a legacy nekoware update in the works. I just know with GCC that it has hard-coded searchpaths from a build so I didn't wanna relocate LLVM via cp commands and have issues. I'm not confident such a thing is still safe to do.

Don't you need python for LLVM and other dependencies?

[vvuk]

Hi folks!  I've just updated the top post to remove the obsolete old info, and add updated links to builds, both standalone and RPM.  Same info duplicated here:

---

Updated: 16 Dec 2021

There are updated builds (version 14.0.0-pre5.2 or newer) available in two forms:

• standlone tar.gz form at: https://misc.bitops.com/llvm-rpms/standalone/
  
• via the SGUG RPM environment using dnf: tdnf install clang libcxx-devel
  

I've been using this for a while to build a variety of things and haven't run into any compiler-related issues.  There are a few env related issues occasionally that are still to be resolved (libcxx provides a hacky vasprintf that may conflict with some other compat library that provides one), but in general it seems stable!  Please enjoy, and if you run into problems, file bugs for me at https://github.com/vvuk/llvm-project/issues

The standalone tarballs use the /usr/sgug prefix that mirrors the rpm releases, but don't require anything from SGUG; if you're not using the RPM environment (you should, so easy!), just treat it as a "sgug" vendor directory :)

This compiler supports both N32 and 64-bit ABIs, but it's only really stable for N32.  It _will_ compile 64-bit binaries, and I include a full libcxx build for 64-bit, but the codegen there is known to be buggy; at the very least, it will commonly emit unaligned loads/stores that need MIPS_FIXADE to be enabled.

I'll be tracking LLVM releases and will aim to get to a stable 14.0.0 release when LLVM itself releases LLVM 14.

[Raion]

Good work. This will soon come in handy for a new project I'm working on.

[Raion]

I don't suppose anyone could enlighten us if there's any new developments for llvm?

I've been attempting to package it but the major blocker is python 3, and the fact that I'm doing a native build. I'm not going to get involved in cross-compiling not because I have anything against it but because it simply wouldn't be practical for me to do.

One of the things that I'm doing to get around the out of memory is looking into trying to get multi-lib GCC support working. I'm also curious if there's any plans to backport irix support to an older LLVM release to enable a leapfrog approach.

I'm afraid that I can't help with any of the code gen related stuff because that's well above my skill level. But I'm still interested in eventually having this be a pertinent alternative if possible.