Regular version bumps

[rubdos]

Hi! Thanks for having Rust on SailfishOS!

Rust is quite a vivid thing. Recently Tokio 1.0 was announced. With this, they committed to keeping a MSRV (minimum supported Rust version) of the last six months of Rust versions:

Tokio will keep a rolling MSRV (minimum supported rust version) policy of 6 months. When increasing the MSRV, the new Rust version must have been released at least six months ago.

Whisperfish recently updated to Tokio 1.0. We always have built using our "own SDK": the Platform SDK + a 💩-load of -path-link statements and include-overrides. This is slow, difficult to maintain, not supported by Jolla, only works on Arch Linux and Debian (afaik), ... Many bad things. We really want to move to the Application SDK!

I would love that SailfishOS tries to keep in sync with Tokio in terms of Rust versions. So, I basically request three things here:

1. A bump to Rust 1.48 (or later, of course. 1.50 came out today!)
2. Tracking some minimum version
3. Documentation on how to build, test and bump this package, such that the community can help in pushing the version.

/cc @kunerd

[abranson]

Hi,

Our Rust version is bound to our Gecko version - unfortunately our attempts to build older Gecko ESRs with newer Rust versions haven't gone well. SFOS 4.0.1 is on Gecko ESR60, so you might have to wait until we catch up with the latest ESR for this.

[rubdos]

Ack, thanks for the swift response! Point 3 would perhaps be possible on a more short term then, I suppose? It's that it would be nice if we could build some rustc for ourselves, knowing that we're very close to what you guys are doing.

[abranson]

Yes, it could be possible, but I've seen this stuff on the periphery and it's hugely complex. There's not just the vanilla rust to build, but also the cross-compilation support, as the native compilation is really slow on ARM iirc. I'll pass this on to someone who might know a bit more about it.

[lbt]

Sure. The spec file is canonical description of how we build rust.
Rust is unusual in that we do not build a version that runs on-device - only one setup to cross-build in the scratchbox2 environment.
The SFOS SDK has recently been tweaked to support building rust code (not rust itself).
Probably the simplest/best way to build rust itself as closely as possible to our internal build would be to use "osc build" against the upcoming release from the platform SDK (that's how I do it).
In the meantime, as I say, the spec file is your best guide to the patches applied and the configuration we use.

One issue we face is that rustc is a native cross compiler which makes assumptions about the environment and the tools around it that don't quite fit with our sb2 model. The other is that cargo is heavily threaded and runs fork/exec which is a known troublesome combination. This triggers hangs when sb2 is interacting heavily through system-call emulation gates between the fork and exec calls. That's what the patches are about.

Hope this helps.

[rubdos]

Thanks a ton! @kunerd is mostly trying to get Rust apps through a more "official" SDK, so I'll leave this to him from here. Thanks for coming back to us! ❤️

[kunerd]

Thank you for taking the time to help us on this. My main problem at the moment is, that if I try to build the current master of this repo by using the following commands:

$ sb2 -t  SailfishOS-3.4.0.24-i486
$ rpmbuild --define "_topdir `pwd`" --define "_sourcedir `pwd`" -bb rust.spec

Everything went fine, until the x.py script tries to start compiling via rustc, because rustc just hangs without cpu usage. That even happens, if I call the unpacked BUILD/rust-1.44.../usr/bin/rustc with -vV. Please forgive me, if I'm doing something terrible wrong, I'm new to building stuff with the PlatformSDK.

By the way, I was able to bake a pre-build rust-1.49 into the AppSDKs Docker container and build an app similar to the example from the docs that even run. So, hopefully newer rust versions will be easier to get integrated into the AppSDK.

[rubdos]

@lbt , thanks again for your comments. I am looking at how to get a newer Rust version, and I'm basing my changes on the Fedora RPM spec. Running rpmbuild in the Platform SDK seems to work until you hit the cross cc: /opt/cross is not mounted. Symlinking it to the SailfishOS-latest tooling in /srv/tooling seems to do a big part of the job, until the cross cc is used for linking, then it cannot find some of the system libraries.

Is there a way for people without an osc account to build this, a way to setup the local environment?

[Thaodan]

The platform SDK should work. If you look at the spec file of xulrunner that should be a good start.

[Thaodan]

One issue we face is that rustc is a native cross compiler which makes assumptions about the environment and the tools around it that don't quite fit with our sb2 model. The other is that cargo is heavily threaded and runs fork/exec which is a known troublesome combination. This triggers hangs when sb2 is interacting heavily through system-call emulation gates between the fork and exec calls. That's what the patches are about.

Hope this helps.

To explain this further:
The scratchbox2 targets and toolings are usually in a symbiotic relationship with the tooling doing the "real" work by using cross compilers build natively for the host arch that build to the target.
With rust this was quite hard to achieve, rust is executed in the host rather than in the tooling.

[rubdos]

Google-fu was a bit hard, for future reference: https://git.sailfishos.org/mer-core/gecko-dev/blob/master/rpm/xulrunner-qt5.spec

[rubdos]

@Thaodan are you suggesting me to build Rust inside sb2, then? Reading that spec, it looks as if that's built inside sb2; I'm mostly wondering how the current rust.spec is built inside osc, what kind of environment that is, why it would work on OBS and not locally.

[rubdos]

Building on a clean platform SDK with the three latest targets: clean-build-1.44.log.

... which gives me the idea to use sudo ln -s /srv/mer/toolings/SailfishOS-latest/opt/* /opt/: ln-opt-cross-1.44.log

FWIW, with my 1.51 patch, this fails instead on
ln-opt-cross-1.51.log

Both seemingly indicating that said symlink is not enough.

[Thaodan]

Please attach full log files and don't copy & paste log files into bugs.

[rubdos]

Apologies. Updated my comment. Please inform if you come to any other conclusion than I did.