Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1114179 > unrolled thread

Bug#1017961: mozjs102: Fails to build on armel

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1017961: mozjs102: Fails to build on armel Jeremy Bicha <jeremy.bicha@canonical.com> - 2022-08-23 02:30 +0200
    Bug#1017961: mozjs102: Fails to build on armel Simon McVittie <smcv@debian.org> - 2022-08-23 11:10 +0200
      Bug#1017961: mozjs102: Fails to build on armel Simon McVittie <smcv@debian.org> - 2022-08-23 14:40 +0200
        Bug#1017961: mozjs102: Fails to build on armel Simon McVittie <smcv@debian.org> - 2022-08-23 22:50 +0200
          Bug#1017961: mozjs102: Fails to build on armel Simon McVittie <smcv@debian.org> - 2022-08-25 12:40 +0200

#1114179 — Bug#1017961: mozjs102: Fails to build on armel

Source: mozjs102
Version: 102.2.0-1
Severity: important
X-Debbugs-CC: debian-arm@lists.debian.org
Tags: ftbfs help

mozjs102 fails to build on armel. This is a problem because it is
blocking us from being able to switch Debian's gjs to use mozjs102
instead of the obsolete mozjs91.

https://buildd.debian.org/status/logs.php?pkg=mozjs102&arch=armel

I did notice this repeatedly in the build log:

{standard input}: Assembler messages:
{standard input}: Error: selected processor does not support `dmb sy'
in ARM mode
{standard input}: Error: selected processor does not support `ldrexb
r0,[r1]' in ARM mode
{standard input}: Error: selected processor does not support `strexb
r3,r2,[r1]' in ARM mode

Thank you,
Jeremy Bicha

[toc] | [next] | [standalone]

#1114206

On Mon, 22 Aug 2022 at 20:25:17 -0400, Jeremy Bicha wrote:
> I did notice this repeatedly in the build log:
> 
> {standard input}: Assembler messages:
> {standard input}: Error: selected processor does not support `dmb sy'
> in ARM mode
> {standard input}: Error: selected processor does not support `ldrexb
> r0,[r1]' in ARM mode
> {standard input}: Error: selected processor does not support `strexb
> r3,r2,[r1]' in ARM mode

I think the answer might be to switch to the fallback atomics
implementation on armel. I'm testing a patch on amdahl, but it's going
to take a while to get a result.

    smcv

[toc] | [prev] | [next] | [standalone]

#1114228

On Tue, 23 Aug 2022 at 10:07:47 +0100, Simon McVittie wrote:
> On Mon, 22 Aug 2022 at 20:25:17 -0400, Jeremy Bicha wrote:
> > I did notice this repeatedly in the build log:
> > 
> > {standard input}: Assembler messages:
> > {standard input}: Error: selected processor does not support `dmb sy'
> > in ARM mode
> > {standard input}: Error: selected processor does not support `ldrexb
> > r0,[r1]' in ARM mode
> > {standard input}: Error: selected processor does not support `strexb
> > r3,r2,[r1]' in ARM mode
> 
> I think the answer might be to switch to the fallback atomics
> implementation on armel. I'm testing a patch on amdahl, but it's going
> to take a while to get a result.

I tried the attached patch and the build gets a lot further, but then
the final link fails for the same reason that I described in #1017979
(which is not a regression in mozjs102, mozjs91 has the same failure).

As a result of the final link failing, I don't know whether tests will
pass with this patch.

The next thing I'm going to try is using gcc 11 on armel as a workaround
for #1017979.

    smcv

[toc] | [prev] | [next] | [standalone]

#1114284

[Multipart message — attachments visible in raw view] — view raw

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786619

On Tue, 23 Aug 2022 at 13:31:21 +0100, Simon McVittie wrote:
> I tried the attached patch

Sorry, now attached.

> The next thing I'm going to try is using gcc 11 on armel as a workaround
> for #1017979.

That worked, but a lot of tests fail, probably as a result of the attached
patch being wrong. But perhaps it's enough to point someone in the right
direction?

    smcv

[toc] | [prev] | [next] | [standalone]

#1114434

On Tue, 23 Aug 2022 at 21:42:29 +0100, Simon McVittie wrote:
> Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786619

Upstream suggested that I should also turn off the JIT (see patch
attached to the upstream bug), but that doesn't seem to have helped with
the test failures. The test suite is segfaulting in most tests in the
Atomics/*/bigint family:

## test262/built-ins/Atomics/xor/bigint/good-views.js: rc = -11, run time = 0.030321
TEST-UNEXPECTED-FAIL | test262/built-ins/Atomics/xor/bigint/good-views.js | (args: "") [0.0 s]
## test262/built-ins/Atomics/xor/bigint/non-shared-bufferdata.js: rc = -11, run time = 0.038158
TEST-UNEXPECTED-FAIL | test262/built-ins/Atomics/xor/bigint/non-shared-bufferdata.js | (args: "") [0.0 s]
## test262/built-ins/Atomics/or/bigint/good-views.js: rc = -11, run time = 0.038281
(etc.)

and there is also a non-segfault test failure:

## test262/built-ins/Atomics/compareExchange/good-views.js: rc = 3, run time = 0.03819
/home/smcv/mozjs-armel/js/src/tests/test262/built-ins/Atomics/shell.js:188:7 uncaught exception: Test262Error: The value of view[3] is 0 Expected SameValue(«-5», «0») to be true (Testing with Int16Array.)
Stack:
  testWithTypedArrayConstructors@/home/smcv/mozjs-armel/js/src/tests/test262/built-ins/Atomics/shell.js:188:7
  @/home/smcv/mozjs-armel/js/src/tests/test262/built-ins/Atomics/compareExchange/good-views.js:16:31
TEST-UNEXPECTED-FAIL | test262/built-ins/Atomics/compareExchange/good-views.js | (args: "") [0.0 s]

I don't have a good picture of where this puts us on a scale from "it's
basically fine" to "armel users will report grave bugs in gjs-based
packages whenever they try to run them, because they're hopelessly
crashy". Does anyone have a better idea of whether these test failures
are ignorable or RC? I don't want to end up in a situation where the
GNOME team is responsible for fixing atomic ops that we don't understand,
on machines that can't run GNOME and are unsupported by upstream, under
the threat of having GNOME removed from Debian if we can't.

I'm doing all this remotely on a porterbox, because my only armel
machine was de-supported in Debian 11 due to kernel size issues and
is headless anyway, so I can't run practical gjs apps on armel myself
(and in any case it would take hours if not days to compile mozjs on
actually-armel hardware).

As another possible route, I've opened a release team bug inquiring about
architecture-specific removals of gjs and rdeps from armel (#1018076).

    smcv

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web