Linux binaries don't run on older machines

[alexcrichton]

Unfortunately to get a "maximally compatible" linux binary it needs to be built on a super-old Linux machine (e.g. CentOS 5). This is what we currently do for our rustc distribution, but otherwise the error message you get looks like:

./multirust: /rustroot/lib64/libcrypto.so.1.0.0: no version information available (required by ./multirust)
./multirust: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./multirust)
./multirust: /rustroot/lib64/libssl.so.1.0.0: no version information available (required by ./multirust)

This should be "easily" available through a docker image of CentOS 5 on Travis. You can see our docker image, although that level of complexity probably isn't necessary (e.g. the custom gcc may not be needed).

Another point is that to distribute a linux binary with SSL support the only robust way I know of is to link OpenSSL statically. Older systems don't have the 1.x releases of OpenSSL and still use 0.9.8, so to work on both you've got to statically link in OpenSSL (e.g. this is what Cargo does).

I can certainly help out with all this stuff as well!

[Diggsey]

I'm rather fond of the fast travis turnaround time atm, although I see the necessity of this.

With regard to openssl, I already specify OPENSSL_STATIC=1, is that not enough?

[alexcrichton]

I'll try out some builds and see how slow pulling the docker image is, but I guess something's not picking up OPENSSL_STATIC?

$ ldd `which multirust`
        linux-vdso.so.1 =>  (0x00007fffc4bfe000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f10bc97b000)
        libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f10bc71c000)
        libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f10bc340000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f10bc13c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f10bbd77000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f10bcfbd000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f10bba70000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f10bb852000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f10bb63c000)

[Diggsey]

Is this fixed now, thanks to #27 ?

[alexcrichton]

Just confirmed it to be fixed, yay!

[Diggsey]

👍