LLVM/clang/lld as an Irix toolchain

Eschaton

New member
Nov 6, 2019
6
1
3
I’ve been experimenting with building LLVM/clang/lld as an Irix toolchain. Some of this is motivated by the fact that professionally I need to stay away from anything GPLv3 and the rest is motivated by the fact that I know a lot of people involved with LLVM and can thus easily ask for their help.

So far I’ve been able to compile a hello world program to a .o but not an executable, and I can’t link the .o on Irix because it appears not to grok some of the ELF features lld is using. Attempting to link on Linux is getting an error due to an unresolved symbol in libc.so, which would normally be filled in by rld. I’ve asked for assistance with this stuff on the cfe-dev list and so far the help has been useful; I figured bringing it up here would be useful too in either inspiring someone else to try something similar or to help debug it.

One thing I can’t do without jumping through a bunch of hoops, alas, is share my code. Hopefully I’ve been detailed enough in my questions that someone else could git clone LLVM’s new monorepo and reproduce my results.

Oh yeah, and to make an Irix SDK, I tarred up the following directories on my Octane with Irix 6.5.30f and MIPSpro 7.4.4m installed:

  • /usr/include
  • /lib
  • /usr/lib
  • /lib32
  • /usr/lib32
  • /lib64
  • /usr/lib64

Then I just extracted them into a directory on my Linux box to pass as -isysroot to the compiler. If there’s anything else that I should grab, please let me know.
 

Unxmaal

Administrator
Feb 8, 2019
98
60
18
I’ve been experimenting with building LLVM/clang/lld as an Irix toolchain. Some of this is motivated by the fact that professionally I need to stay away from anything GPLv3 and the rest is motivated by the fact that I know a lot of people involved with LLVM and can thus easily ask for their help.

So far I’ve been able to compile a hello world program to a .o but not an executable, and I can’t link the .o on Irix because it appears not to grok some of the ELF features lld is using. Attempting to link on Linux is getting an error due to an unresolved symbol in libc.so, which would normally be filled in by rld. I’ve asked for assistance with this stuff on the cfe-dev list and so far the help has been useful; I figured bringing it up here would be useful too in either inspiring someone else to try something similar or to help debug it.

One thing I can’t do without jumping through a bunch of hoops, alas, is share my code. Hopefully I’ve been detailed enough in my questions that someone else could git clone LLVM’s new monorepo and reproduce my results.

Oh yeah, and to make an Irix SDK, I tarred up the following directories on my Octane with Irix 6.5.30f and MIPSpro 7.4.4m installed:

  • /usr/include
  • /lib
  • /usr/lib
  • /lib32
  • /usr/lib32
  • /lib64
  • /usr/lib64
Then I just extracted them into a directory on my Linux box to pass as -isysroot to the compiler. If there’s anything else that I should grab, please let me know.
Take a look at Compilertron: https://github.com/unxmaal/compilertron .

It's a vagrant VM that does all of this for you.

I haven't used it in a bit, but it worked the last time I tried it.

(I'll note that cross-compiling is fraught with disaster and pitfalls. You might want to look at using didbs natively on your Octane, which is a few posts down from this one in this forum.)
 

Eschaton

New member
Nov 6, 2019
6
1
3
Thanks! I’d rather get “real” support via LLVM though, especially given that I have to stay away from GPLv3 code.
 

hammy

Active member
Jun 1, 2019
108
68
28
UK
Hi Eschaton - welcome!

You've made it rather tricky to collaborate - no code exchange and can't see GPL code .-) (I do understand this is possibly employer mandated + I've personally already enough on my plate a.t.m. ).

Since no code exchange, the only help I can offer would be some documentation I've picked up on my travels for mips, elf and the various pieces. Maybe you already have these, maybe you don't. Find em attached.

RE: rld_new_interface - like you we see that this is a symbol filled in by the runtime linker when the binaries is mapped into memory. For our gcc projects where this is a problem we use `--allow-unresolved=all` as a current workaround.

I haven't had the time to look deeper in binutils why - but I vaguely remember there being some flag or switch within the ELF object that should indicate that "this symbol can remain unresolved" - but I never had the time to go further.

Best of luck.
 

Attachments

  • Like
Reactions: Elf

Eschaton

New member
Nov 6, 2019
6
1
3
Thanks for the references! They’ll be useful as I pick this back up. I had some life stuff to deal with over the past couple months.
 

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu