mips64el machine - mrustc

mips64el machine - mrustc

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

Hi,

does anyone have a mips64el machine?
Could I have an (unprivileged) account on one for a little while?

I'm trying to get mrustc to work on mips64el, but I don't have such a machine and
transparent Guix qemu-binfmt-service-type doesn't seem to work for it either
(but does work for aarch64 and arm, WTF?).

Alternatively, I can also send a few commands for you to execute there.

What I'd need is:

* Find out what the gcc triplet is
* Test the mrustc patch I have done to get https://github.com/daym/mrustc/tree/mips64 .
  This means: make -f minicargo.mk
* Build rust@1.19.0 in current guix master.
  This means: guix build rust@1.19.0


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: mips64el machine - mrustc

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> does anyone have a mips64el machine?
> Could I have an (unprivileged) account on one for a little while?

Those we had behind hydra.gnu.org died a couple of years ago…

> I'm trying to get mrustc to work on mips64el, but I don't have such a machine and
> transparent Guix qemu-binfmt-service-type doesn't seem to work for it either
> (but does work for aarch64 and arm, WTF?).

Out of curiosity, how does it fail?  I use it for ARMv7 and AArch64,
where it indeed works nicely.

Thanks,
Ludo’.

Re: mips64el machine - mrustc

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

Hi Ludo,

> Out of curiosity, how does it fail?  I use it for ARMv7 and AArch64,
> where it indeed works nicely.

$ ./pre-inst-env guix build -s mips64el-linux mrustc
...
Building /gnu/store/q2x2bxk8xda18aa2xfnvig3rgl4q7xlm-guile-bootstrap-2.0.drv - mips64el-linux
@ unsupported-platform /gnu/store/q2x2bxk8xda18aa2xfnvig3rgl4q7xlm-guile-bootstrap-2.0.drv mips64el-linux
while setting up the build environment: a `mips64el-linux' is required to build `/gnu/store/q2x2bxk8xda18aa2xfnvig3rgl4q7xlm-guile-bootstrap-2.0.drv', but I am a `x86_64-linux'
builder for `/gnu/store/q2x2bxk8xda18aa2xfnvig3rgl4q7xlm-guile-bootstrap-2.0.drv' failed with exit code 1
Build failed:  /gnu/store/q2x2bxk8xda18aa2xfnvig3rgl4q7xlm-guile-bootstrap-2.0.drv - 1 builder for `/gnu/store/q2x2bxk8xda18aa2xfnvig3rgl4q7xlm-guile-bootstrap-2.0.drv' failed with exit code 1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: mips64el machine - mrustc

[Mark H Weaver]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:
> does anyone have a mips64el machine?
> Could I have an (unprivileged) account on one for a little while?
>
> I'm trying to get mrustc to work on mips64el, but I don't have such a machine and
> transparent Guix qemu-binfmt-service-type doesn't seem to work for it either
> (but does work for aarch64 and arm, WTF?).

Thanks for working on our Rust packages, and for making sure the other
architectures are not left in the cold.  I truly appreciate it!

As far as I can tell, I'm the only user of Guix on MIPS in recent years.
I still have a working Yeeloong laptop based on Loongson 2F, which is
running a modified GuixSD.  The most notable modification is that my
GuixSD system on mips64el is based on older binutils (2.25.1), because
I've found that running code built by later versions of binutils causes
my Yeeloong to lock up hard at some random time during compilation.  I
guess it's because either the assembler or the linker is producing code
that tickles a bug in the Loongson 2F, but I've not yet found the energy
to get to the bottom of this issue.

Anyway, the situation is that our MIPS port is more or less "on ice",
meaning that it could be revived with modest effort, but at the present
time there's not enough developer attention to keep it functional.

So, please don't worry about MIPS support in Rust for now.

Thanks again for your work on our Rust packages.  It's a great help!

      Mark

Question about Rust bootstrap

[Mark H Weaver]

Hi Danny,

Speaking of our Rust packages, I have a question: is it intentional that
'rust-1.23' is still built using 'rust-bootstrap' and not 'rust-1.22'?

The reason I ask is that, to my delight, there appears to be (almost?)
everything needed for a complete source-only bootstrap chain for recent
Rust:

* rust-1.19.0 is built using mrustc
* rust-1.20.0 is built using rust-1.19.0
* rust-1.21.0 is built using rust-1.20.0
* rust-1.22.1 is built using rust-1.21.0
* rust-1.23.0 is built using pre-built 'rust-bootstrap' (1.22.1)  (???)
* rust-1.24.1 is built using rust-1.23.0
* rust-1.25.0 is built using rust-1.24.1
* rust-1.26.2 is built using rust-1.25.0
* rust-1.27.2 is built using rust-1.26.2

This chain would be complete if 'rust-1.23' were built using 'rust-1.22'
instead of 'rust-bootstrap'.  Since both 'rust-1.22' and
'rust-bootstrap' are apparently for the same version of Rust (1.22.1),
I would naturally expect one to work in place of the other one.
Have you tried it?

      Thanks,
        Mark

Re: Question about Rust bootstrap

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 3321 bytes --]

Hi Mark,

On Thu, 20 Sep 2018 02:35:27 -0400
Mark H Weaver <mhw@netris.org> wrote:

> Speaking of our Rust packages, I have a question: is it intentional that
> 'rust-1.23' is still built using 'rust-bootstrap' and not 'rust-1.22'?

Yes, because I'm not done yet :)

> The reason I ask is that, to my delight, there appears to be (almost?)
> everything needed for a complete source-only bootstrap chain for recent
> Rust:
> 
> * rust-1.19.0 is built using mrustc
> * rust-1.20.0 is built using rust-1.19.0
> * rust-1.21.0 is built using rust-1.20.0
> * rust-1.22.1 is built using rust-1.21.0
> * rust-1.23.0 is built using pre-built 'rust-bootstrap' (1.22.1)  (???)
> * rust-1.24.1 is built using rust-1.23.0
> * rust-1.25.0 is built using rust-1.24.1
> * rust-1.26.2 is built using rust-1.25.0
> * rust-1.27.2 is built using rust-1.26.2
> 
> This chain would be complete if 'rust-1.23' were built using 'rust-1.22'
> instead of 'rust-bootstrap'.  Since both 'rust-1.22' and
> 'rust-bootstrap' are apparently for the same version of Rust (1.22.1),
> I would naturally expect one to work in place of the other one.
> Have you tried it?

rust 1.20.0 has a failure when creating the documentation (check phase)
because it does not create "version_info.html" from "version_info.html.template"
- although it should.  On the other hand it passes all the tests (about 7000
of them).

I'm investigating why the documentation does not build.

Every guix build rust takes about half a day to complete on my machine, so it
will still take a week or so I'd say.

The build rule for version_info.html is in src/bootstrap/doc.rs , search
for "version_info.html".

I'm tempted to just patch "!up_to_date(&version_input, &version_info)" out of
it - but maybe it's covering up a deeper issue.

There's this:

pub fn mtime(path: &Path) -> FileTime {
    fs::metadata(path).map(|f| {
        FileTime::from_last_modification_time(&f)
    }).unwrap_or(FileTime::zero())
}

pub fn up_to_date(src: &Path, dst: &Path) -> bool {
    let threshold = mtime(dst);
    let meta = match fs::metadata(src) {
        Ok(meta) => meta,
        Err(e) => panic!("source {:?} failed to get metadata: {}", src, e),
    };
    if meta.is_dir() {
        dir_up_to_date(src, &threshold)
    } else {
        FileTime::from_last_modification_time(&meta) <= threshold
    }
}

So what if the destination does not exist?
Then the source would have to have zero timestamp for up_to_date to return true
(which we don't want), right?
So we should have non-zero timestamps for source files.
And I've checked the guix-build-rust directory, they all have timestamps of zero.

Sigh.  So I'll change all the source timestamps to 1, problem maybe solved.
Rebuilding...

Aha, newer rust version have:

pub fn up_to_date(src: &Path, dst: &Path) -> bool {
    if !dst.exists() { //             !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
        return false;
    }
    let threshold = mtime(dst);
    let meta = match fs::metadata(src) {
        Ok(meta) => meta,
        Err(e) => panic!("source {:?} failed to get metadata: {}", src, e),
    };
    if meta.is_dir() {
        dir_up_to_date(src, threshold)
    } else {
        meta.modified().unwrap_or(UNIX_EPOCH) <= threshold
    }
}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: mips64el machine - mrustc

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

Hi Mark,

On Thu, 20 Sep 2018 01:49:05 -0400
Mark H Weaver <mhw@netris.org> wrote:

> So, please don't worry about MIPS support in Rust for now.
> 
> Thanks again for your work on our Rust packages.  It's a great help!

Thanks!

Okay, I'll just leave MIPS support off for now.

I'll keep the github branch online.
It contains my patch for MIPS for mrustc which is not in upstream.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

mips64el port

[Ludovic Courtès]

Hello Mark,

Mark H Weaver <mhw@netris.org> skribis:

> Anyway, the situation is that our MIPS port is more or less "on ice",
> meaning that it could be revived with modest effort, but at the present
> time there's not enough developer attention to keep it functional.

What do you think would be the best course of action with our mips64el
port now?

Our documentation should probably reflect the fact that it’s not
receiving much attention, for instance by removing mentions of it from
the manual and web site, and optionally by having ‘configure’ reject it
unless ‘--with-courage’ is passed.

Another approach would be to get build machines (possibly via the
qemu-binfmt service), though if there are few users that may not help
much.  Or we could try to make GuixSD a viable option for mips-based
routers that typically run OpenWRT, though that’s a bit ambitious…

Thoughts?

Ludo’.

Re: mips64el machine - mrustc

[Andreas Enge]

Hello Danny,

I have a mips64 machine (the mini-pc desktop version of Mark's laptop,
with only one core). It is excruciatingly slow (if I remember well, just
compiling guix takes a few hours) and makes a tractor like noise, so I
turned it off and moved it to my closet. But I could take it out again
and try to let it run during the day when I am not there, and see if
I manage to upgrade Guix on it.

Andreas

Re: mips64el machine - mrustc

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> Hello Danny,
>
> I have a mips64 machine (the mini-pc desktop version of Mark's laptop,
> with only one core). It is excruciatingly slow (if I remember well, just
> compiling guix takes a few hours) and makes a tractor like noise, so I
> turned it off and moved it to my closet. But I could take it out again
> and try to let it run during the day when I am not there, and see if
> I manage to upgrade Guix on it.

Based on my own experience with my Yeeloong, I suspect you will find
that machines based on Loongson 2F will lock up at some point during the
bootstrap when using binutils newer than 2.25.1.  It would be
interesting to confirm or deny this hypothesis.

       Mark