I get the same error on loading 'wl' (and the exact same 19 unknown
symbols in dmesg) from installing bcmwl-kernel-source on Xenial.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1745256
Title:
>From what I can tell the maintainers have no intention of spending time
supporting Ubuntu 16.04 or older. Even when Xenial was the current LTS
they weren't responding here, and now that 18.04 has been out for 5
month there's even less motivation to handle older distros.
Having built Firefox 59
Lars, I went to sites like Gmail or Youtube that I thought had a chance
of using optional NaCl, but I haven't been able to reproduce those error
messages. I don't think Firefox supports NaCl, even with a plugin. Is it
possible you imported browser settings from Chromium and it happened to
include
@herrtimson I looked in the tarball and don't even see mention of my use
of clang in mozconfig.
Note I'm using a procedure similar to what Chituc outlined. If I kick
off dpkg-buildpackage, interrupt it, then edit the generated backend.mk
I would not expect that to appear in patch files. It's also
@herrtimson
Here's a 14.04 Trusty build:
https://www.dropbox.com/s/977vzb3mu8bf34z/firefox_59.0.2%2Bbuild1-0ubuntu0.14.04.4_armhf.deb?dl=0
I used the same approach with clang + gcc headers inside a Trusty
(gcc-4.8) container. Initially I got errors about ::gets() and Stack
Overflow sent me down
@herrtimson from my tests that patch does not resolve the strd r2, r3,
[r1] crash on Xenial. However, I do believe it's entirely possible that
it indirectly fixed the issue with your gcc-7 toolchain. I'm starting to
wonder if this crash does not have a single cause but rather is a
codepath that
@herrtimson are you expecting revert-128661.patch to fix the strd r2,
r3, [r1] startup segfault on xenial/trusty, the Skia assembly illegal
instruction, or both?
The discussion in bug 1434526 indicates this patch is necessary on
Firefox 60 to resolve an armhf build failure on the latest trunk,
Here is a working Firefox 59 deb package cross-compiled for 18.04 armhf:
https://www.dropbox.com/s/17ypog6btdq4wj7/firefox_59.0.1%2Bbuild1-0ubuntu1_armhf.deb?dl=0
I have installed and tested on RaspEX (Bionic armhf). I can also confirm
it works sandboxed on Ubuntu MATE Xenial and Raspbian
@levente (and maybe @herrtimson),
I set up a new Ubuntu MATE system, and in the process realized that your
segfault in /lib/ld-linux-armhf.so.3 is a symptom of bug 1576432. That's
where gdb fails not only for Firefox but even a simple helloworld
program. The workaround there is to install
Thanks @Chris!
@herrtimson you can do this:
layout asm
tui disable
set logging on
disas /r ,
It'll save the output of your disas command to gdb.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@herrtimson we already confirmed that the gcc-7 / Bionic build crashes
on the exact same misaligned instruction in Skia. See responses #48 and
#50 for how I tested this, the point being that waiting for Bionic alone
won't fix this.
Diagnosing a corrupt stack: whether you have debug symbols or not
@Chituc,
I attempted to set up an Ubuntu 14.04 Firefox build environment, and am
realizing how difficult it is to troubleshoot something old and barely
supported.
Instead, could you take your existing 16.04 build flow but run sudo apt
install g++-4.8 then build with CC=gcc-4.8, CXX=g++-4.8?
Ugh, yeah doing some simple helloworld tests confirms these are armhf
gcc *defaults*.
> it's what *defines* armhf as armhf.
Defines: This appears true for -march=armv7-a -mfloat-abi=hard. As for
-mfpu, adding -mfpu=neon results in some assembly differences, namely
using register d16 and above.
> [herrtimson] I wrote an email to Chris Coulson, asking for some
assistance with the cflags. Hopefully he'll read it.
Thanks. I flagged him on #ubuntu-devel IRC as well. Hopefully we'll get
his attention this time.
> > [Chituc] Can you check if the firefox 57.04 trusty , the working one shows
Awesome, thanks for confirming Arch still works and posting the
screenshot.
> Also anyone tried to run the binary from bionic, which should be built
with gcc-7 as well?
Yes, Lars and I both tried this. It's rather buried in discussion above
but search for the part where I mention "ignore the
I think we just have the IRC logs that Chituc posted, no bug id.
When I searched https://bugs.chromium.org/p/skia/issues/list last months
for issues with the keyword "armhf" I did not find any such bug filed.
At the time I was about to file a ticket myself, but that made me first
run through the
> By the way I managed to set up a cross compile development
That's great news. Could you post your instructions? This would allow
others here to help out, considering most of us don't have ARM boards
with much RAM or 20 hours of patience.
This also opens up the possibility of making a build on
There was a typo in my above post, should say javascript.enabled, but
I'll assume you didn't have the extra dot when tried yesterday.
> I installed debug symbols
I just realized this makes it sound like you installed firefox-dbg,
which would give incorrect addresses because those symbols are for
Nice work!
If you edit your prefs.js to disable JIT (javascript.options.baselinejit
= false) or try to disable JavaScript altogether (java.script.enabled =
false), does it crash at the same point?
(I would expect so as these flags have not helped much when
troubleshooting in the past, but it's
That's an interesting idea. As I mentioned above chromium-browser builds
with -mthumb so it's possible this is a key flag.
Sorry to hear that Firefox does not build with clang out of the box.
Another possible approach is to build the majority of Firefox with gcc
but the Skia portion in clang. You
I see. You're right, the kernel is aarch64 but the compiler and build
tools are armhf. The chromium-browser build log reports the same, so
cross-compilation might not be necessary.
> If you can help with what mods are required to make it compile with
clang I can try to compile it in a armhf
Thanks for trying that, Lars. libfontconfig 2.11 vs 2.12 should be
compatible so you could force it to ignore the dependency or run in a
sandbox dir without installing. For example: ar xv
firefox_58.0.2+build1-0ubuntu1_armhf.deb; tar xvf data.tar.xz; cd
./usr/lib/firefox; ./firefox
This gave me
Thanks Chituc. That's spot-on with the identical error in Firefox.
Specifically, it's not an illegal instruction so much as a misaligned
(+2 bytes) instruction, plus at that point it's in Thumb mode when
anything inside SkJumper should be in ARM mode.
Technically both firefox and chromium-browser
Various notes:
Good point by Chituc. I had assumed this was already cross-compiled, but
according to the Ubuntu build log:
> checking whether cross compiling... no
Who here knows how the Arch Linux armhf package is built?
It's also still possible that a newer toolchain could fix things. I read
Darn, and I see the same error with Firefox 59. Your stack trace still
shows the illegal instruction in sk_xor__vfp4(). It seems like something
is now running Skia even when it's disabled in the config.
Among rendering differences, from the Firefox 58 blog post there's those
changes for OMTP
levente,
I'm not sure how Lars and Sam Tygier (#1732954) are getting useful
backtraces. Might have something to do with running 17.10?
> ii firefox 57.0.4+build1-0ubuntu0.16.04.1 armhf
I see you're using 16.04. I should have mentioned that the workaround of
disabling Skia is something I
Thanks for providing the stack trace, Lars.
This shows the illegal instruction is happening in Skia, specifically
SkJumper's implementation of _sk_xor__vfp4. To run with Skia disabled,
edit your user profile at ~/.mozilla/firefox/*.default/prefs.js and add
the following line:
That fix was:
> * Hopefully fix LP: #1711337 by building the armhf build with
> -fno-schedule-insns to work around a compiler bug
?
According to
https://launchpadlibrarian.net/351233449/buildlog_ubuntu-xenial-armhf.firefox_57.0.3+build1-0ubuntu0.16.04.1_BUILDING.txt.gz
it's building with:
28 matches
Mail list logo
