SunOS/Solaris/Illumos support

[awatkins1966]

Problem you are trying to solve

Follow up to a closed issue SunOS/Solaris/Illumos support #1320

As of now Solaris ships with rustc 1.53.0 and cargo 1.53 and now "Common Build Environment (CBE) releases for the Oracle Solaris 11.4" the use of it could increase.

Also, more applicationes are using rust and rustup i.e. https://www.clamav.net/ now requires rust to deploy the very popular Virus scanner.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

rustup: unrecognized OS type: SunOS

Thanks again for your great work.

Andrew

Solution you'd like

rustup to work with SunOS

Notes

No response

[kinnison]

The patch we were given expects that Illumos will give uname -o of illumos in order that it can transform SunOS into illumos for the OS detection. This patch is in the current version of rustup released, so it'd be useful to know if you lack uname -o returning illumos or if it's something else.

[awatkins1966]

Thanks.

On Oracle Solaris systems the -o option returns Solaris

$ uname -o Solaris

Great news.

[kinnison]

If you download the rustup-init.sh file and tweak it so that when it encounters that uname -o it still assumes the Illumos binary will work, does the resultant downloaded version of rustup work?

[awatkins1966]

Thanks, I tried that: if [ "$(/usr/bin/uname -o)" = Solaris ]; then _ostype=illumos fi but then I get + /tmp/tmp.F6ReAd/rustup-init ld.so.1: rustup-init: fatal: libc.so.1: version 'ILLUMOS_0.4' not found (required by file /tmp/tmp.F6ReAd/rustup-init) ld.so.1: rustup-init: fatal: /tmp/tmp.F6ReAd/rustup-init: mismatched ELF symbol versioning /var/tmp/rustup-init.sh: line 451: 12571 Killed "$@" Which makes since it downloads //static.rust-lang.org/rustup/dist/x86_64-unknown-illumos/rustup-init and I guess uses the _ostype "illumos"! Thanks

[awatkins1966]

Should add the ldd output:

$ ldd /tmp/tmp.F6ReAd/rustup-init
       libsocket.so.1 =>        /lib/64/libsocket.so.1
        librt.so.1 =>    /lib/64/librt.so.1
        libpthread.so.1 =>       /lib/64/libpthread.so.1
        libresolv.so.2 =>        /lib/64/libresolv.so.2
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        libumem.so.1 =>  /lib/64/libumem.so.1
        libgcc_s.so.1 =>         /usr/lib/64/libgcc_s.so.1
        libc.so.1 =>     /lib/64/libc.so.1
        **libc.so.1 (ILLUMOS_0.4) =>       (version not found)
        libc.so.1 (ILLUMOS_0.15) =>      (version not found)
        libc.so.1 (ILLUMOS_0.12) =>      (version not found)**
        libm.so.2 =>     /lib/64/libm.so.2
        libssp.so.0 =>   /usr/lib/64/libssp.so.0
        libucrypto.so.1 =>       /lib/64/libucrypto.so.1
        libelf.so.1 =>   /lib/64/libelf.so.1
        libcryptoutil.so.1 =>    /lib/64/libcryptoutil.so.1
        libbsm.so.1 =>   /lib/64/libbsm.so.1
        libz.so.1 =>     /lib/64/libz.so.1
        libtsol.so.2 =>  /lib/64/libtsol.so.2
        libinetutil.so.1 =>      /lib/64/libinetutil.so.1

[kinnison]

OK, so this tells us that illumos has sufficiently different symbols that we're not going to be able to use the illumos rustup binary on true solaris. So the next steps would be to work out what extra bits we'll need in rustup in order to support solaris. You can do this by building it locally with whatever compiler you do have and then trying to use it to acquire a new compiler. I imagine there'll be some tweaks in our platform support code (grep the codebase for illumos and check around there for solaris stuff). Independently we need to understand if there's an appropriate docker for us to cross-build a release rustup. If not, then it'll beup to solaris to distribute a package, in which case I can help you to understand the best way to do that, so that you don't end up with the sort of mess that homebrew has right now.