Rust snapshot binaries aren't recognized by RHEL5

[brson]

The elf we generate uses the Linux ABI, which is a recent invention, older Linuxes having used the System V ABI. On Scientific Linux 5 this results in the snapshots being unrunnable:

libcore-14bd852465126fe7-0.1.so: ELF file OS ABI invalid

See http://stackoverflow.com/questions/7647818/glibc-elf-file-os-abi-invalid

[graydon]

Seriously? To support STT_GNU_IFUNC? Come on.

I think this is likely happening well below the tools we're actually in control of. BFD (driven by ld) is probably writing that field. And/or the LLVM linker when or if we use it.

[brson]

Updated the title to reflect that this is a problem with the Rust snapshots, not the Rust compiler.

[graydon]

Possibly there is some flag we can invoke ld with that tells it not to do this nonsense? We're not using STT_GNU_IFUNC and I dearly hope it doesn't infect upwards from glibc doing so.

[thoughtpolice]

After doing some searching I cannot find a way to actually set the ELF ABI from GCC/LD's command line; but the FreeBSD dudes luckily have a wonderful utility known as brandelf which can do this for you. It's trivially compilable on Linux (with a few modifications,) and then you can set the ABI back to SVR4 by saying:

$ ./brandelf -t SVR4 ./a.out

This of course only applies to snapshots, since on old systems the linker will build using SVR4 ABI anyway. Doing it this way of course adds another step in the process of building snapshots, but as that seems like a rather infrequent event I think it's fine.

If this seems like an OK route (I think it's fine considering it's very self contained and just uses libelf for the heavy lifting,) I'll cook up a patch to add brandelf.c to the build system and run it over the snapshots.

[graydon]

I'm still digging around on this. It's possible we could use brandelf but there are larger and more mysterious issues at work here:

• Why does Scientific Linux 5 not support the Linux ABI? (how many linuxes this old exist?)
• Why are we producing it if we're not actually using any of the symbol-types that require it? (I'm talking to a binutils author about this presently)

IOW, issue still ongoing, don't hack around it just yet.

[graydon]

I'm going to switch over to ubuntu for a bit to diagnose this further. If the ABI is understood on both RHEL and ubuntu, I'm going to recommend deferring this to 0.3 or later since the majority of our users will be bootstrapping on one or the other.

[graydon]

Wait, is this RHEL5 stock, not just the scientific-linux rebuild? RHEL5 has a long-term support lifecycle stretching to ... 2020!

[graydon]

Further digging, it appears this was fixed with a recent update to binutils, such that you only get the new ABI if you actually include an STT_GNU_IFUNC definition, rather than reference it. So I've updated the BFDs on the linux buildhosts and am redoing a snap. Will ask for confirmation tomorrow.

[graydon]

This should now be fixed (as of 071dedd). Anyone with such an old system want to confirm?

[graydon]

I did even-more-filing-down on this bug (disabling recent glibc symbols in libuv / librustrt) in commit bd03998. Now I really really think it ought to work :)

[grahame]

Hi Graydon

I've patched the python build scripts to work with Python 2.4 (see pull request). Unfortunately it won't build on my machine.

toula::~/code/rust $ cat /etc/redhat-release
CentOS release 5.7 (Final)
toula::~/code/rust $ make
cfg: shell host triple i686-unknown-linux-gnu
cfg: host for i686-unknown-linux-gnu is i386
cfg: unix-y environment
cfg: using gcc
cfg: no pandoc found, omitting doc/rust.pdf
cfg: no llnextgen found, omitting grammar-verification
cfg: no pandoc found, omitting library doc build
compile: rt/i686-unknown-linux-gnu/rust.o
cc1plus: warnings being treated as errors
./src/rt/util/indexed_list.h: In instantiation of ‘indexed_list<rust_task>’:
./src/rt/rust_task_thread.h:50:   instantiated from here
./src/rt/util/indexed_list.h:29: warning: ‘class indexed_list<rust_task>’ has virtual functions but non-virtual destructor
make: *** [rt/i686-unknown-linux-gnu/rust.o] Error 1
zsh: 6475 exit 2     make

That's with the default C++ compiler:

Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)

[grahame]

Ah, apologies - I see now I've completely missed the point, and should have had newer Python and g++. Sorry!

[graydon]

No worries, I'm finding -- pressing onwards on this -- that it's quite involved (will require changing bits of llvm possibly to not use iostreams and such) and I'm not going to be able to finish it in a reasonable timeframe. The original title of the bug is now closed (the binaries are now recognized) so I'm going to ask that we split this up into followup bugs for "general backwards compatibility in older linuxes". I don't think we're going to have 0.2 building on stock RHEL5. Too much is different at this point, not enough porting effort available.