Support configure for illumos or solaris (including SmartOS)

[potatosalad]

This pull request removes some non-POSIX bashisms found in the configure script (namely local scope variables) and adds the x86_64-sun-solaris build triple so that configure can successfully run on Solaris based operating systems (like SmartOS).

The configure script also behaves as a shell wrapper for /usr/bin/ksh if it detects that /bin/sh (or any other non-POSIX shell) is being used on SunOS. The problem is that the /bin/sh built into SunOS is not POSIX compliant, rather than there being an POSIX compliance issue with the configure script itself. Dash explicitly supports local scope variables as a non-POSIX extension, which may be why that specific bashism has remained unnoticed. I wonder how many more times I can fit the word POSIX into this already POSIX filled paragraph?

See also #21000, #25845, #25846, and #25889.

Question about next steps for building on SmartOS:

I still have yet to successfully build rust on SmartOS, although these changes to the configure process have gotten me a little further down the building road. What would be the next steps for getting a stage0 snapshot built for SmartOS? That's about as far down the compilation process as I've been able to go.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[eefriedman]

What would be the next steps for getting a stage0 snapshot built for SmartOS? That's about as far down the compilation process as I've been able to go.

#26682 should give you some idea what's necessary. (You'll have to cross-compile the first snapshot.)

[alexcrichton]

r? @brson

[brson]

Does Solaris's shell really not support local? This is the one bashism that it's common to accept in sh scripts because life without it is not worth living. (e.g. shellfire allows local).

All our shell scripts are currently intended to be POSIX+local compatible.

Edit: ah, I see you mentioned that SunOS shell isn't a POSIX shell.

[brson]

You mention SunOS several times. Do you mean that literally, or do you mean Solaris? Isn't SunOS ancient?

Edit: looks like Solaris identifies itself as SunOS

[brson]

Is ksh available by default? IOW, will this branch always catch SunOS and switch to ksh?

[brson]

Can you add a comment explaining the function of POSIX_SHELL here?

[potatosalad]

Yes, when it re-executes this script under ksh, having POSIX_SHELL already set prevents it from entering an infinite loop of executing ksh. Instead, it continues with the rest of the script.

[brson]

I'd like to come up with a solution that doesn't require giving up local - if we did have to make this change it will ultimately impact a lot of other shell scripts too, and it's just too hard to maintain complex shell scripts without local scope.

[brson]

Shellfire claims Solaris ksh supports local. Can this strategy of execing ksh work generally for us? For example, it wouldn't work with rustup.sh piped into a shell the way its normally used since there's no on-disk script to re-execute.

[potatosalad]

@brson SunOS is what is currently returned from uname -s on my SmartOS machine that was built September 17, 2015. x86_64-sun-solaris is the recognized LLVM triple. As much as I'd like to just name everything "illumos" or "smartos", the underlying "sunos" and "solaris" terms will probably stick around to confuse people for years to come 😄 I'll use "illumos" for the rest of this comment where possible.

ksh93 is the variant that is included with illumos, which shellfire mentions is not supported. ksh93 does support local variables, but through the use of the typeset command.

I think it would be cleaner to just have a shell wrapper for /bin/bash or /usr/bin/env bash instead of /usr/bin/ksh when illumos is detected, but I noticed in the other issues you were wanting to stress non-bash compliance.

Would adding back the local definitions and changing the above shell wrapper to the following work for you?

# /bin/sh on Solaris is not a POSIX compatible shell, but bash is.
if [ `uname -s` = 'SunOS' -a "${POSIX_SHELL}" != "true" ]; then
    POSIX_SHELL="true"
    export POSIX_SHELL
    exec /usr/bin/env bash $0 "$@"
fi
unset POSIX_SHELL # clear it so if we invoke other scripts, they run as bash as well

[brson]

@potatosalad Yes, your proposed solution works. Thanks!

[sigil66]

Using this commit the next blocker (for illumos based systems) was here (before I realized I would have to cross compile the first snapshot) https://llvm.org/bugs/show_bug.cgi?id=25409 this is an LLVM issue, but worthy of a note.

[nbaksalyar]

@sigil66 Yeah, I stuck on it with my porting attempt as well. There are many more issues to fix, though. Want to cooperate? :) I'm about half-way there with the Solaris/Illumos-specific constants & structs.

[sigil66]

@nbaksalyar sure I can attempt to help. Do you have a branch anywhere? My next step was to start slogging through this: http://rust-on-haiku.com/wiki/PortingRust

[nbaksalyar]

@sigil66 yes, I have my branch, but I haven't pushed the latest changes yet, though. I'm going to do a little clean up first.

Any help would speed up the porting process tremendously, so I'll highly appreciate it - it'd be awesome to run Rust natively on Solaris with full DTrace support (not to mention an option to run it natively on Joyent's Triton). Even better if anyone has a commercial interest in it. :)

Overall, it seems to me there are more people trying to achieve the same goals, and I think we should consolidate our efforts.

[sigil66]

+1

[potatosalad]

@nbaksalyar @sigil66 Have either of you had any luck with getting a cross-compiler that targets illumos to bootstrap rust?

There was a brief conversation about bootstrapping a new platform on #rust back in September 2015, but I didn't get very far due to lack of time.

[sigil66]

@potatosalad same, all I can really find about the process is detailed in that haiku link.

[nbaksalyar]

@potatosalad I don't think it differs much from other platforms. I use a NetBSD port (+ another pull request) as a reference, and here is another resource that I've found: Cross Bootstrapping Rust.

For now the progress is blocked by the LLVM bug, but it can be temporarily fixed as described (i.e., by removing the unsupported discard-unused=sections linker flag). What remains to be done is a careful comparison and porting of libc structs, functions, and constants, as they're almost entirely different on Solaris. Perhaps this process can be automated, but I do it manually by looking up structs in /usr/include on SmartOS. This way I've ported about 30-40% of them, but I've stumbled upon another compilation error, only now it's jemalloc - it's something like

checking whether a program using ffsl is compilable... no
configure: error: Cannot build without ffsl(3) or __builtin_ffsl()

I haven't made any more progress since then. So, as I see, now there is another spark of interest in the port, so here's my plan:

1. First, I'm going to try to figure out how the issue with jemalloc can be fixed;
2. I'll try to get a stage 0 compiler binary for Solaris (it might not be working, but at least it should compile without errors);
3. I'll push my libc changes and from there on we can proceed to try to bootstrap the compiler and make all the tests green. I think this would be a huge task, so it'd be awesome if anyone is willing to collaborate on this one.

I'll update on the progress in this issue. Any comments? :)

[sigil66]

@nbaksalyar sounds great, will try to help!

[nbaksalyar]

compilation error, only now it's jemalloc - it's something like
configure: error: Cannot build without ffsl(3) or __builtin_ffsl()

OK, so that issue turned out to be quite simple: it's because jemalloc makefile adds some Solaris libraries to linker flags (e.g. -lposix4 -lsocket), and as they're not available on Linux, the linking and, consequently, the feature check fails.

I fixed it by specifying the path to an Illumos sysroot, which contains /usr/include, /usr/lib, and /lib files copied from a SmartOS image. Now compilation proceeds, but there are more errors because of platform-specific code in libstd that's yet to be ported.

I'll keep updating.

[nbaksalyar]

Well, after a couple of long days of struggle with weird compilation errors, I managed to build the stage0 rustc that targets x86_64-sun-solaris!

It compiles without any errors, though binaries that it produces throw out an error Illegal Instruction (core dumped) upon running.

I bet it's because of some missing struct/const definitions in the liblibc module, but I can't check this yet because on my computer rustc build process is quite painful (each slightest change in liblibc results in a 40-60 mins rebuild). But I'm almost certain that tomorrow we'll see the first Rust program that runs on Illumos. :)

[potatosalad]

@nbaksalyar That's awesome news! If you want any help deciphering the core dumps or access to a more powerful machine to speed up compile times, I might be able to help out in that area. Let me know if you're interested.

[nbaksalyar]

Now it's getting fun - we've passed a major milestone and got a working rustc compiler on Illumos that self-compiles! :)

You can grab the rustc build here: https://s3-eu-west-1.amazonaws.com/nbaksalyar/rustc-1.7.0-dev-x86_64-sun-solaris.tar.gz. It's just a copy of stage2/bin and stage2/lib files (you probably should have GCC 4.8 installed to run this).

Sources are here (in the solaris branch):
https://github.com/nbaksalyar/rust/tree/solaris
https://github.com/nbaksalyar/rust-libc

It should compile as-is, you just have to run configure with --enable-local-rust and --local-rust-root=<path to a pre-compiled rustc> flags.

Here's a quick rundown on what's yet to be done:

• At the moment there's one major blocker preventing a merge with the master branch: the LLVM linker flags incompatibility. Hopefully it'll be fixed soon, but at the moment LLVM's configure has to be patched.
• The compiler should be thoroughly tested. I don't have much time to do this, so any help here would be much appreciated!
• There's a couple of dirty hacks in the ported source that I don't like. In particular, handling of a dirent structure - it should be rewritten in a more meaningful and clear way.
• Stack unwind isn't working yet, it has to be debugged and fixed.
• Cargo has to be ported as well.

Overall, it's not too complex, so I hope that we'll get to rustc being available in pkgsrc soon. :)

@potatosalad

access to a more powerful machine to speed up compile times, I might be able to help out in that area.

Thanks, that would be super useful to have! Please drop me a message at nikita.baksalyar@gmail.com.

[brson]

Huh, there's no real reason this shouldn't have landed by now. Just me not paying attention.

I wonder if we should just give up on sh. Jumping through a hoop to reexecute this script in bash just on Solaris is pretty crazy. I've already converted multirust to bash.

@potatosalad bash is always available on IllumOS? Presumably you are hitting trouble with other scripts that require sh as well?

I've filed a new issue about converting sh to bash: #31036.

[nbaksalyar]

Hi @brson!

I believe bash is the primary shell on Illumos-derived operating systems (I'm not sure about Oracle's Solaris, though). It'd be nice if you merge this pull request, as the "controversial" configure script is one of the last bits required to add the support for Illumos to Rust. I'm maintaining my fork here: https://github.com/nbaksalyar/rust/commits/solaris.

It already passes most of the tests (run-pass, run-fail, and others), so I'm planning to wrap it up and send as a pull request today or tomorrow. The required libc changes are already landed: rust-lang/libc#138. I hope it's OK to choose you as a reviewer.

So it would be awesome to have this PR merged first. :)

[brson]

@nbaksalyar Would redirecting to bash instead of ksh work for you? That would let us keep the local declarations. If so, I would more happily accept that patch.

[bors]

☔ The latest upstream changes (presumably #31078) made this pull request unmergeable. Please resolve the merge conflicts.

[potatosalad]

Closing in favor of #31078 which has been merged.