Preliminary MIPS N32 port now available

Preliminary MIPS N32 port now available

[Mark H Weaver]

Hello all,

If you own a 64-bit MIPS system (including Loongson 2F), are willing to
build everything on your own machine, and would like to try out the
preliminary port of Guix to MIPS N32, the "loongson" branch of the Guix
git repo is ready for your early testing.

If you run into a 'match-error', try "make clean".  This is needed
because of recent unrelated changes on the master branch.

Please let us know how it goes!

    Regards,
      Mark

Re: Preliminary MIPS N32 port now available

[Andreas Enge]

Hi Mark,

On Thu, Oct 17, 2013 at 11:19:02PM -0400, Mark H Weaver wrote:
> If you own a 64-bit MIPS system (including Loongson 2F), are willing to
> build everything on your own machine, and would like to try out the
> preliminary port of Guix to MIPS N32, the "loongson" branch of the Guix
> git repo is ready for your early testing.

these are very good news indeed, congratulations!

It looks like the branch is based on master; if it is supposed to be merged
into core-updates, had it not better be based on core-updates?

Andreas

Re: Preliminary MIPS N32 port now available

[Nikita Karetnikov]

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

> If you own a 64-bit MIPS system (including Loongson 2F), are willing to
> build everything on your own machine, and would like to try out the
> preliminary port of Guix to MIPS N32, the "loongson" branch of the Guix
> git repo is ready for your early testing.

> If you run into a 'match-error', try "make clean".  This is needed
> because of recent unrelated changes on the master branch.

> Please let us know how it goes!

Thanks for your work, Mark.  I’ll try and report back.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Preliminary MIPS N32 port now available

[Mark H Weaver]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> On Thu, Oct 17, 2013 at 11:19:02PM -0400, Mark H Weaver wrote:
>> If you own a 64-bit MIPS system (including Loongson 2F), are willing to
>> build everything on your own machine, and would like to try out the
>> preliminary port of Guix to MIPS N32, the "loongson" branch of the Guix
>> git repo is ready for your early testing.
>
> these are very good news indeed, congratulations!
>
> It looks like the branch is based on master; if it is supposed to be merged
> into core-updates, had it not better be based on core-updates?

I considered this, but since it takes so long to compile things on the
Loongson 2F, I wanted to start on a more stable branch.  Also, several
important fixes that I need are on master but not yet in core-updates.

More importantly, because there are so many patches for Loongson 2F that
are not yet ready to be applied upstream -- either because they are not
sufficiently clean, or because they choose a compile-time configuration
that uses Loongson-specific features or works around Loongson 2F bugs --
I expect that we'll want to maintain a separate "loongson" branch for
the foreseeable future, even if some of the patches are applied to
core-updates.

For example, 'pixman', used by both the X server and Cairo for low-level
rendering operations, optionally includes code to use Loongson-specific
SIMD vector instructions, but the choice of whether to use this code
must be made at compile time.  The Loongson-specific code makes a
dramatic improvement in rendering performance, but won't work at all on
other MIPS processors.

Because of this, we will need different 'pixman' packages for Loongson
and other MIPS processors.  Furthermore, because of the way Guix/Nix
works, it means that we need separate builds of everything that depends
on 'pixman' (which includes Cairo and Gtk and everything that uses Gtk).

Ideally, 'pixman' would be modified to detect the processor type at run
time, and then dynamically choose which code to use based on that.  If
someone would like to do that, it would be a most welcome development :)

However, 'pixman' is only one of many such examples.  Actually, it's one
of the better examples, because at least in that case, the Loongson
support is in the upstream version.  In many other cases, the Loongson
patches have not been accepted upstream (or were never submitted),
usually because they are not of sufficient quality.

For these reasons, I think we will need the 'loongson' branch for some
time to come.

What do you think?

      Mark

Re: Preliminary MIPS N32 port now available

[Ludovic Courtès]

Hi Mark!

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

> If you own a 64-bit MIPS system (including Loongson 2F), are willing to
> build everything on your own machine, and would like to try out the
> preliminary port of Guix to MIPS N32, the "loongson" branch of the Guix
> git repo is ready for your early testing.

Woow, excellent news!

Andreas Enge <andreas@enge.fr> skribis:

> It looks like the branch is based on master; if it is supposed to be merged
> into core-updates, had it not better be based on core-updates?

Agreed.

Thanks,
Ludo’.

Re: Preliminary MIPS N32 port now available

[Andreas Enge]

On Fri, Oct 18, 2013 at 11:41:24AM -0400, Mark H Weaver wrote:
> More importantly, because there are so many patches for Loongson 2F that
> are not yet ready to be applied upstream -- either because they are not
> sufficiently clean, or because they choose a compile-time configuration
> that uses Loongson-specific features or works around Loongson 2F bugs --
> I expect that we'll want to maintain a separate "loongson" branch for
> the foreseeable future, even if some of the patches are applied to
> core-updates.

Personally, I think mips64el should be a fully qualified release architecture
just as i686 and x86_64. So it would be better to have it in master and
not in a separate branch.

So far, the only machines of this architecture available (and of interest)
to developers are loongson. So I would argue that for the time being,
mips64el=loongson, and all patches necessary for loongson should be applied
to master (assuming they do not interfere with i686 and x86_64, which I would
not expect for decent patches that could be sent upstream). Maybe we might
wish to keep a "loongson" in the name of the patches to make them easily
identifiable.

> For example, 'pixman', used by both the X server and Cairo for low-level
> rendering operations, optionally includes code to use Loongson-specific
> SIMD vector instructions, but the choice of whether to use this code
> must be made at compile time.  The Loongson-specific code makes a
> dramatic improvement in rendering performance, but won't work at all on
> other MIPS processors.

Under the assumption mips64el=loongson, this would then not be a problem,
and we would use the compiler flags needed to enable loongson optimisations
on the mips64el architecture.

If potentially in the future someone comes up who can contribute to a
non-loongson mips64el port and has a corresponding machine, then we can
revise our policy, maybe by creating a new branch, maybe by considering
more fine-grained architectures (using the vendor field of the quadruple?).

Andreas

Re: Preliminary MIPS N32 port now available

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Fri, Oct 18, 2013 at 11:41:24AM -0400, Mark H Weaver wrote:
>> More importantly, because there are so many patches for Loongson 2F that
>> are not yet ready to be applied upstream -- either because they are not
>> sufficiently clean, or because they choose a compile-time configuration
>> that uses Loongson-specific features or works around Loongson 2F bugs --
>> I expect that we'll want to maintain a separate "loongson" branch for
>> the foreseeable future, even if some of the patches are applied to
>> core-updates.
>
> Personally, I think mips64el should be a fully qualified release architecture
> just as i686 and x86_64. So it would be better to have it in master and
> not in a separate branch.
>
> So far, the only machines of this architecture available (and of interest)
> to developers are loongson.

I agree.  Let’s not go ahead of ourselves: when someone comes up with a
plan to use Guix on a mips64el machine that is not Loongson, then we can
adapt (and it’s great that you know about all these Loongson workarounds.)

WDYT?

Ludo’.

Re: Preliminary MIPS N32 port now available

[Mark H Weaver]

Hi Andreas and Ludovic!

ludo@gnu.org (Ludovic Courtès) writes:

> Andreas Enge <andreas@enge.fr> skribis:
>
>> Personally, I think mips64el should be a fully qualified release architecture
>> just as i686 and x86_64. So it would be better to have it in master and
>> not in a separate branch.
>>
>> So far, the only machines of this architecture available (and of interest)
>> to developers are loongson.
>
> I agree.  Let’s not go ahead of ourselves: when someone comes up with a
> plan to use Guix on a mips64el machine that is not Loongson, then we can
> adapt (and it’s great that you know about all these Loongson workarounds.)

Okay, sounds good.  However, since it takes me over a week to rebuild
even a basic system after a core package has changed, I need to start by
building on a more stable base.  That will allow me to find problems
higher up in the software stack and apply patches as needed.

In the meantime, feel free to apply any commits from the "loongson"
branch to core-updates.  The current set of commits should be fine, but
later on, I'll probably push some things to "loongson" that you won't
want in master.  It would be nice if all of the important Loongson
patches were ready to send upstream, but unfortunately many of them are
not.

So while I certainly agree that the ultimate goal should be to
eventually eliminate the "loongson" branch, I expect it will be some
time before we can do that.

      Mark

Re: Preliminary MIPS N32 port now available

[Ludovic Courtès]

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

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andreas Enge <andreas@enge.fr> skribis:
>>
>>> Personally, I think mips64el should be a fully qualified release architecture
>>> just as i686 and x86_64. So it would be better to have it in master and
>>> not in a separate branch.
>>>
>>> So far, the only machines of this architecture available (and of interest)
>>> to developers are loongson.
>>
>> I agree.  Let’s not go ahead of ourselves: when someone comes up with a
>> plan to use Guix on a mips64el machine that is not Loongson, then we can
>> adapt (and it’s great that you know about all these Loongson workarounds.)
>
> Okay, sounds good.

Cool.

> However, since it takes me over a week to rebuild even a basic system
> after a core package has changed, I need to start by building on a
> more stable base.  That will allow me to find problems higher up in
> the software stack and apply patches as needed.

Yeah, so I guess it’s fine to work on something based on ‘master’ if
that’s more convenient for you.  Eventually all this will be merged one
way or the other anyway.  :-)

> So while I certainly agree that the ultimate goal should be to
> eventually eliminate the "loongson" branch, I expect it will be some
> time before we can do that.

Seems to me that the main (or only?) condition that must hold before the
branch can be merged in ‘master’ is that it must not trigger a rebuild
for the other arches.

Then, even if it’s still WIP, it won’t harm if it’s in ‘master’, and it
may get more attention.

Thanks,
Ludo’.

Re: Preliminary MIPS N32 port now available

[Nikita Karetnikov]

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

I tried to build ‘hello’ twice, and the following error occurred each
time:

stripping binaries in "/nix/store/hl8khv4qip9nwbm1qm93irbz9has4wrd-gcc-cross-boot0-4.7.3/bin" with "strip" and flags ("--strip-debug")
phase `strip' succeeded after 17 seconds
error (ignored): aborting transaction: cannot rollback - no transaction is active
guix package: error: build failed: committing transaction: disk I/O error

I guess something is wrong with my system, what should I check?

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Preliminary MIPS N32 port now available

[Mark H Weaver]

Hi Nikita,

Nikita Karetnikov <nikita@karetnikov.org> writes:

> I tried to build ‘hello’ twice, and the following error occurred each
> time:
>
> stripping binaries in
> "/nix/store/hl8khv4qip9nwbm1qm93irbz9has4wrd-gcc-cross-boot0-4.7.3/bin"
> with "strip" and flags ("--strip-debug")
> phase `strip' succeeded after 17 seconds
> error (ignored): aborting transaction: cannot rollback - no transaction is active
> guix package: error: build failed: committing transaction: disk I/O error
>
> I guess something is wrong with my system, what should I check?

I looked into this, and the problem is an incompatibility between SQLite
and JFS.  When SQLite commits a transaction, it uses 'fsync' on a
directory, which is apparently not supported by JFS.  This problem was
noticed by an AIX user back in 2008.  It looks like they worked around
the problem by changing SQLite's behavior on AIX systems, but that
obviously doesn't help you.

  http://news.gmane.org/group/gmane.comp.db.sqlite.general/thread=39682

I think your best option is to switch back to ext3 or ext4.

     Mark

Re: Preliminary MIPS N32 port now available

[Mark H Weaver]

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

> Hi Nikita,
>
> Nikita Karetnikov <nikita@karetnikov.org> writes:
>
>> I tried to build ‘hello’ twice, and the following error occurred each
>> time:
>>
>> stripping binaries in
>> "/nix/store/hl8khv4qip9nwbm1qm93irbz9has4wrd-gcc-cross-boot0-4.7.3/bin"
>> with "strip" and flags ("--strip-debug")
>> phase `strip' succeeded after 17 seconds
>> error (ignored): aborting transaction: cannot rollback - no transaction is active
>> guix package: error: build failed: committing transaction: disk I/O error
>>
>> I guess something is wrong with my system, what should I check?
>
> I looked into this, and the problem is an incompatibility between SQLite
> and JFS.  When SQLite commits a transaction, it uses 'fsync' on a
> directory, which is apparently not supported by JFS.  This problem was
> noticed by an AIX user back in 2008.  It looks like they worked around
> the problem by changing SQLite's behavior on AIX systems, but that
> obviously doesn't help you.
>
>   http://news.gmane.org/group/gmane.comp.db.sqlite.general/thread=39682
>
> I think your best option is to switch back to ext3 or ext4.

I looked further into this, and it seems that newer versions of SQLite
handle this more gracefully.  In the version I have on my home-grown
system (sqlite-autoconf-3070603), it appears that they ignore this
error.  There's also a preprocessor define you can set called
SQLITE_DISABLE_DIRSYNC.

I still think it's probably a good idea to switch away from JFS, since
you're likely to run into other problems like this, but if you really
want to stick with JFS, compiling a newer version of SQLite and then
reconfiguring and rebuilding Guix might get you past this immediate
problem.

     Mark

Re: Preliminary MIPS N32 port now available

[Nikita Karetnikov]

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

> I think your best option is to switch back to ext3 or ext4.

Thanks, will do.

I was told to switch to JFS to avoid ext-specific issues; I’m laughing
out loud now, haha.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Preliminary MIPS N32 port now available

[Nikita Karetnikov]

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

> I still think it's probably a good idea to switch away from JFS, since
> you're likely to run into other problems like this,

I see this as an opportunity to report problems.

> but if you really
> want to stick with JFS, compiling a newer version of SQLite and then
> reconfiguring and rebuilding Guix might get you past this immediate
> problem.

I think I’ll try the new version of SQLite.  That should be faster.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Preliminary MIPS N32 port: IMPORTANT CAVEAT

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:
> If you own a 64-bit MIPS system (including Loongson 2F), are willing to
> build everything on your own machine, and would like to try out the
> preliminary port of Guix to MIPS N32, the "loongson" branch of the Guix
> git repo is ready for your early testing.

It's worth noting that you should *not* use "guix pull" on this branch,
because that would effectively switch you over to the master branch,
which does not yet support MIPS or Loongson properly.

     Mark

Re: Preliminary MIPS N32 port now available

[Nikita Karetnikov]

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

First, I upgraded and tried again, but got the same error.  Then, I
defined SQLITE_DISABLE_DIRSYNC and got this one:

stripping binaries in "/nix/store/1n843qz1psmp3bvx6hk1gj3mp1akdama-glibc-intermediate-2.18/sbin" with "strip" and flags ("--strip-debug")
debugging output written to "/nix/store/zcml8660gkcd84laj3h1yr30vz4dvgxq-glibc-intermediate-2.18-debug" using "objcopy"
phase `strip' succeeded after 652 seconds
guix package: error: build failed: cannot close compressed log file (BZip2 error = -6)

I couldn’t find anything on the web.  Do you have any ideas?  If not,
I’ll switch to ext3.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Preliminary MIPS N32 port now available

[Mark H Weaver]

Nikita Karetnikov <nikita@karetnikov.org> writes:

> First, I upgraded and tried again, but got the same error.  Then, I
> defined SQLITE_DISABLE_DIRSYNC and got this one:
>
> stripping binaries in
> "/nix/store/1n843qz1psmp3bvx6hk1gj3mp1akdama-glibc-intermediate-2.18/sbin"
> with "strip" and flags ("--strip-debug")
> debugging output written to "/nix/store/zcml8660gkcd84laj3h1yr30vz4dvgxq-glibc-intermediate-2.18-debug" using "objcopy"
> phase `strip' succeeded after 652 seconds
> guix package: error: build failed: cannot close compressed log file (BZip2 error = -6)

I think you should switch away from JFS.  We have more important things
to work on than figuring out why a bunch of code fails to work on JFS.

     Mark

Important libffi bug fix for MIPS N32

[Mark H Weaver]

Hello MIPS Guix!

A failing test in glib alerted me to a bug in libffi on MIPS N32.  I've
pushed a fix[*] to the 'loongson' branch.  It will require rebuilding
quite a few packages, so I recommend aborting whatever builds you have
running, and pulling the latest 'loongson' before continuing.

     Best,
      Mark

[*] http://git.savannah.gnu.org/cgit/guix.git/commit/?h=loongson&id=376069c09e796b6aef9eb3a524c991c4a41ff594

Re: Important libffi bug fix for MIPS N32

[Nikita Karetnikov]

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

> A failing test in glib alerted me to a bug in libffi on MIPS N32.  I've
> pushed a fix[*] to the 'loongson' branch.  It will require rebuilding
> quite a few packages, so I recommend aborting whatever builds you have
> running, and pulling the latest 'loongson' before continuing.

I successfully built ‘hello’ after switching to ext3.  Now, should I
test the mentioned fix?

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: Important libffi bug fix for MIPS N32

[Mark H Weaver]

Nikita Karetnikov <nikita@karetnikov.org> writes:

>> A failing test in glib alerted me to a bug in libffi on MIPS N32.  I've
>> pushed a fix[*] to the 'loongson' branch.  It will require rebuilding
>> quite a few packages, so I recommend aborting whatever builds you have
>> running, and pulling the latest 'loongson' before continuing.
>
> I successfully built ‘hello’ after switching to ext3.

That's good news :)

> Now, should I test the mentioned fix?

Yes, please do!

    Mark

Re: Important libffi bug fix for MIPS N32

[Andreas Enge]

On Wed, Oct 23, 2013 at 01:11:50AM -0400, Mark H Weaver wrote:
> A failing test in glib alerted me to a bug in libffi on MIPS N32.  I've
> pushed a fix[*] to the 'loongson' branch.

Excellent! Did you report it upstream?

Andreas

Re: Important libffi bug fix for MIPS N32

[Nikita Karetnikov]

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

(Not sure why my previous messages weren’t signed.)

>> Now, should I test the mentioned fix?

> Yes, please do!

The coreutils package fails to build:

FAIL: test-fchownat (exit: 134)
===============================

test-chown.h:193: assertion failed

[…]

======================================
1 of 295 tests failed
(22 tests were not run)
See gnulib-tests/test-suite.log
Please report to bug-coreutils@gnu.org
======================================
make[6]: *** [test-suite.log] Error 1
make[6]: Leaving directory `/tmp/nix-build-coreutils-8.21.drv-0/coreutils-8.21/gnulib-tests'
make[5]: *** [check-TESTS] Error 2
make[5]: Leaving directory `/tmp/nix-build-coreutils-8.21.drv-0/coreutils-8.21/gnulib-tests'
make[4]: *** [check-am] Error 2
make[4]: Leaving directory `/tmp/nix-build-coreutils-8.21.drv-0/coreutils-8.21/gnulib-tests'
make[3]: *** [check-recursive] Error 1
make[3]: Leaving directory `/tmp/nix-build-coreutils-8.21.drv-0/coreutils-8.21/gnulib-tests'
make[2]: *** [check] Error 2
make[2]: Leaving directory `/tmp/nix-build-coreutils-8.21.drv-0/coreutils-8.21/gnulib-tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/tmp/nix-build-coreutils-8.21.drv-0/coreutils-8.21'
make: *** [check] Error 2
phase `check' failed after 1756 seconds
builder for `/nix/store/09i57yii00zj9jgwlakfch928ppdkiq7-coreutils-8.21.drv' failed with exit code 1
@ build-failed /nix/store/09i57yii00zj9jgwlakfch928ppdkiq7-coreutils-8.21.drv - 1 builder for `/nix/store/09i57yii00zj9jgwlakfch928ppdkiq7-coreutils-8.21.drv' failed with exit code 1
cannot build derivation `/nix/store/a1ilh9ml81j1mm645rsp9ha7aqh3c48a-hello-2.8.drv': 1 dependencies couldn't be built
guix package: error: build failed: build of `/nix/store/a1ilh9ml81j1mm645rsp9ha7aqh3c48a-hello-2.8.drv' failed

Should I provide more information?

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Important libffi bug fix for MIPS N32

[Mark H Weaver]

Nikita Karetnikov <nikita@karetnikov.org> writes:

> The coreutils package fails to build:
>
> FAIL: test-fchownat (exit: 134)
> ===============================
>
> test-chown.h:193: assertion failed

Hmm.  The same derivation (with the same hash) passes this test and
builds successfully on my YeeLoong.  Perhaps the problem is related to
the kernel you're using?  I built it on linux-libre-3.10.15.

In any case, since I'm unable to reproduce the problem on my end, you'll
need to take the lead on debugging this.  I'd recommend building it
again using "guix build -K" so that the build directory is kept, and
then you can investigate further.  There might be a log file associated
with that test with more information, or perhaps you can run the test
manually under a debugger or under strace and find out more.

You could also try a newer kernel.  As you probably know, the
Linux-libre project builds Loongson-patched kernels for gNewSense:

  http://linux-libre.fsfla.org/pub/linux-libre/lemote/gnewsense/pool/

linux-image-3.10.17-gnu_0loongsonlibre_mipsel.deb would correspond most
closely to what worked for me, though beware that on my system at least,
the wireless driver hangs the system, so I have to use ethernet instead.

   Good luck!
      Mark

Re: Important libffi bug fix for MIPS N32

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> On Wed, Oct 23, 2013 at 01:11:50AM -0400, Mark H Weaver wrote:
>> A failing test in glib alerted me to a bug in libffi on MIPS N32.  I've
>> pushed a fix[*] to the 'loongson' branch.
>
> Excellent! Did you report it upstream?

Yes: http://article.gmane.org/gmane.comp.lib.ffi.general/1004

   Thanks,
     Mark

Re: Preliminary MIPS N32 port: IMPORTANT CAVEAT

[Ludovic Courtès]

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

> Mark H Weaver <mhw@netris.org> writes:
>> If you own a 64-bit MIPS system (including Loongson 2F), are willing to
>> build everything on your own machine, and would like to try out the
>> preliminary port of Guix to MIPS N32, the "loongson" branch of the Guix
>> git repo is ready for your early testing.
>
> It's worth noting that you should *not* use "guix pull" on this branch,
> because that would effectively switch you over to the master branch,
> which does not yet support MIPS or Loongson properly.

Alternately you can use:

  guix pull --url=http://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-loongson.tar.gz

although it’s arguably not very convenient.

Ludo’.

Re: Important libffi bug fix for MIPS N32

[Ludovic Courtès]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

> (Not sure why my previous messages weren’t signed.)
>
>>> Now, should I test the mentioned fix?
>
>> Yes, please do!
>
> The coreutils package fails to build:
>
> FAIL: test-fchownat (exit: 134)
> ===============================
>
> test-chown.h:193: assertion failed

This line is:

--8<---------------cut here---------------start------------->8---
      ASSERT (st1.st_ctime < st2.st_ctime
              || (st1.st_ctime == st2.st_ctime
                  && get_stat_ctime_ns (&st1) < get_stat_ctime_ns (&st2)));
--8<---------------cut here---------------end--------------->8---

(See <http://git.savannah.gnu.org/cgit/gnulib.git/tree/tests/test-chown.h#n191>.)

Could it have something to do with nanosecond-resolution timestamp
support in the kernel that’s running, or in the underlying file system?

Ludo’.

Re: Important libffi bug fix for MIPS N32

[Mark H Weaver]

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

> Andreas Enge <andreas@enge.fr> writes:
>
>> On Wed, Oct 23, 2013 at 01:11:50AM -0400, Mark H Weaver wrote:
>>> A failing test in glib alerted me to a bug in libffi on MIPS N32.  I've
>>> pushed a fix[*] to the 'loongson' branch.
>>
>> Excellent! Did you report it upstream?
>
> Yes: http://article.gmane.org/gmane.comp.lib.ffi.general/1004

They committed my patch without changes.

https://github.com/atgreen/libffi/commit/d3372c54ce7117e80d389ba875dc5b6b2213c71e

     Mark

Re: Important libffi bug fix for MIPS N32

[Nikita Karetnikov]

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

> This line is:

>       ASSERT (st1.st_ctime < st2.st_ctime
>               || (st1.st_ctime == st2.st_ctime
>                   && get_stat_ctime_ns (&st1) < get_stat_ctime_ns (&st2)));

> (See <http://git.savannah.gnu.org/cgit/gnulib.git/tree/tests/test-chown.h#n191>.)

> Could it have something to do with nanosecond-resolution timestamp
> support in the kernel that’s running, or in the underlying file system?

Mark suggested to try again.  I retried, and it passed all 295 tests.
Should I test anything else?

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Important libffi bug fix for MIPS N32

[Ludovic Courtès]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

>> This line is:
>
>>       ASSERT (st1.st_ctime < st2.st_ctime
>>               || (st1.st_ctime == st2.st_ctime
>>                   && get_stat_ctime_ns (&st1) < get_stat_ctime_ns (&st2)));
>
>> (See <http://git.savannah.gnu.org/cgit/gnulib.git/tree/tests/test-chown.h#n191>.)
>
>> Could it have something to do with nanosecond-resolution timestamp
>> support in the kernel that’s running, or in the underlying file system?
>
> Mark suggested to try again.  I retried, and it passed all 295 tests.

Well, it could be that the test is flaky then.  Too bad the ‘ASSERT’
macro doesn’t provide more info when it fails.

Ludo’.