>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 fr
** Branch linked: lp:~mozillateam/thunderbird/thunderbird.cosmic
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
To manage notifi
so the next update for thunderbird will carry this error?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
To manage notifications
** Branch linked: lp:~mozillateam/thunderbird/thunderbird.bionic
** Branch linked: lp:thunderbird/stable
** Branch linked: lp:~mozillateam/thunderbird/thunderbird.trusty
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.la
** Branch linked: lp:~mozillateam/thunderbird/thunderbird-beta.bionic
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
To manage n
still fails over and over again with 14.04 and 16.04!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
To manage notifications abo
** Also affects: ubports-frieza
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
To ma
Thanks Mathias and Donald (comments 39 & 40)
after update to v61, Firefox crashes when lunched
Now, It works for me after installing v 57.0.4
Thanks a lot again for your help
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs
Firefox working too on armhf xubuntu 18.04! (Pi 3B)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
To manage notifications about
firefox 60.0+build2-0ubuntu1 is launching for me without crashing (on
ubuntu-mate 18.04 on rasberrypi 2B). I have not made any other changes.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Titl
Hi everybody, Mozilla developer here, I've come across this after we
noticed the crash spike on our servers. The relevant bug is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1452128
Unfortunately the symbols for this package weren't uploaded to our
servers so we don't have a useful stack tra
James,
Sorry, I had to report that the bug appeared only when starting
Firefox the first time since then everything is ok.
Regards Lars
On 5/6/18, James Donald <1711...@bugs.launchpad.net> wrote:
> Lars, I went to sites like Gmail or Youtube that I thought had a chance
> of using optional NaCl,
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 t
Well, for me it doesn't really work. Downloaded this deb file from the
github repo: firefox_59.0.2.build1-0ubuntu0.14.04.4_armhf.deb ,
installed it with dpkg -i , and got the error of 'ungültiger
maschienenbefehl', which I am not sure what it does mean at all. Could
be illegal assembler instruction
Hi Donald,
I am writing this e-mail using your new
firefox_59.0.2+build1-0ubuntu0.14.04.4_armhf.deb version on a
TinkerOS, Debian GNU/Linux 9.4 (stretch) , kernel 4.4.71+
I started firefox in Downloads folder from terminal and got the following lines:
linaro@tinkerboard:~/Downloads$ firefox
[fresh]
@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
Fine!!
I installed this to my new tinkerboard ubuntu 16.04, Armbian kernel 4.4.120.
Seems to work fine.
Best regards Lars Nyqvist
On 5/4/18, James Donald <1711...@bugs.launchpad.net> wrote:
> @herrtimson
>
> Here's a 14.04 Trusty build:
> https://www.dropbox.com/s/977vzb3mu8bf34z/firefox_59.0
With debian file I mean the xz file which has all the patches, build
scripts and so on, it should be called
firefox_59.0.2+build1-0ubuntu0.14.04.4.debian.tar.xz
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net
Ah, cool thing! Could you please post a split patch against the debian
file, so that I can see what you have changed exactly and how?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Fir
@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 s
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-7798
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
To manage
@jdonald Wow (& sound a hats being taken off).
That really moves the boat forward - well done!
I did wonder what it was that allowed arch to work, and had a hunch that it
would be hiding in plain sight in their PKGBUILD file, if only I could
understand it.
Thank you for all that work - & your up
@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 Fir
The patch unbreaks the compile of firefox-60 betas on armhf, but at the
same time it fixes the startup segfault which I had with the toolchain
pasted in #120 with stable firefox.
The skia thing could be another story, therefore it would be helpfull to
test build this with a trusty toolchain, or xe
@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, but
toolchain used is:
glibc-2.25, binutils-2.29.1, gcc-7.3.0
rust-1.24.1, cargo 0.25.0, and llvm/clang-5
please test this with trusty toolchain!
** Attachment added: "firefox-59.0.2-arm-gcc7.png"
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1711337/+attachment/5103738/+files/firefox-
This patch should make it work! I was more lucky than anything else,
because there is a compile error with firefox-60.0 betas on armhf which
made me find https://bugzilla.mozilla.org/show_bug.cgi?id=1434526
** Bug watch added: Mozilla Bugzilla #1434526
https://bugzilla.mozilla.org/show_bug.cgi?
Great , thank you ! I have a special build of skia dir I will try this
into your build and see if it will work with skia asm anabled . Thanks
again for hard work !
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.
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 Stretch.
The fix from 59.0.1 to 59.0.2 is literally two lines, it shouldn't be a
problem.
Thank you for all of your effort, what you write about the messy
assembler code seems reasonable. The more I read through the comments in
that file, the more I wonder how this could ever worked out in the past.
There
@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 libc6-db
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.
https://bugs.launchpad.net/bu
@jdonald: how can I direct the output of 'layout asm' from gdb into a
textfile?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
T
I thought it might be useful for you folks who have compiling experience
to compare the compiler switches used in the Trusty build for 57.04 with
those from Arch 59.0 (from post #90), so I've listed them in columns
(attached), after I attempted to pull the switches out of @herrtmison's
screenshot (
@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
If I use gcc-6.4.0 to compile with -g I get the same corrupt stack error
as @levente before. Currently thinking about upgrading to gcc-7, as a
last ressort, or waiting for bionic release in roughly a month or so.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Ubuntu builds firefox for trusty with g++-4.9 , I checked this on amd64
some time ago and the build logs tell me that the armhf toolchain is as
well g++-4.9
0:08.79 checking for the target C++ compiler...
/<>/firefox-59.0.1+build1/debian/gcc-mozilla/g++
0:08.90 checking whether the target C++ c
@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?
Ther
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.
>
CFLAGS="-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16" is the default
for armhf. In fact, it's what *defines* armhf as armhf. Unless
something is explicitly setting those things differently, they don't
need to be on the commandline at all.
--
You received this bug notification because you are
> [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
"-
The attachment "firefox-esr-arm-clang-FREEBSD.patch" seems to be a
patch. If it isn't, please remove the "patch" flag from the attachment,
remove the "patch" tag, and if you are a member of the ~ubuntu-
reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user o
This is the freebsd patch from their bug report. It was generated
against their ports tree, I edited it so that it can be applied against
the firefox source tree instead. This is not an official patch, and it
fixes freebsd only, but still it might be helpfull to see what they
changed. It is confirm
there is one bug at mozilla about clang and arm, but it is more about
android, I guess. Still:
https://bug635044.bugzilla.mozilla.org/show_bug.cgi?id=1163171
Also freebsd builds with clang by default, they have a bug with a patch to fix
it at their end for armv7, it might be possible to adapt thi
I wrote an email to Chris Coulson, asking for some assistance with the
cflags. Hopefully he'll read it.
What you're saying about hardware requirements is not really true.
Firefox is pretty demanding in terms of memory, yes, but per job mostly.
On amd64 and if you build with gcc, it needs roughly 7
I never talked with a ubuntu package manager and I do not know anybody
... I have a HTC 10 phone with 4 gb ram that I can use to try to build
firefox on it . I did not used it till now cacse I use it without swap
and firefox team say we need at least 8 gb ram to compile ff . Are you
sure 2 gb ram a
Hmm, why don't you poke the person who's responsible for the packaging
with this, to adjust the build script in a matter of passing different
cflags if using armv7 and trusty? I'm not really keen on setting up a
specific chroot for trusty, mostly because I have a limited internet
connection. The co
We think CFLAGS="-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16" will prevent
the skia crash .
But firefox must be build using trusty cause xenial builds have at least 2
crashes . (skia and smth else) .
The trusty build crash just if skia is enabled and we think building
firefox using trusty an
If you have a good intel cpu and 16 gb ram ,you can just install using sbuild
the trusty armhf and use it to compile . It will take no more than 3 days to
compile on a i7 intel cpu .
It will take longer than it took inside my real arm hardware because it use
qemu , but will not take more than 3
@Chituc #92 : don't think I can provide about:buildconfig from 57.x ,
because they segfault. If there's a chance to get the output of
about:buildconfig regardless the segfault at startup, I'm all eager to
learn about this.
On trusty, one can see the browser window maybe for 1/3 of a second or
so,
But there is a big hope the build for trusty with "-march=armv7-a
-mfloat-abi=hard -mfpu=vfpv3-d16" will not crash .Builing on xenial
did nto worked but a build in trusty have great chances to work .
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subs
Ok , I did not tried firefox 59 but my firefox 58.02armhf build with
this options "-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16" was
compiled fine by gcc under Ubuntu 16.04 and there was still a crash .
You can read the crah cause I post earlier . Is not the skia crash , is another
one that h
@Chituc:
I’m still running that build from my Debian aid environment so just checked now.
It’s not showing those flags in about:buildconfig
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Can you check if the firefox 57.04 trusty , the working one shows
"-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16" in about:buildconfig ?
I'm thinking that "-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16" are
automaticaly added when you build something with gcc in Ubuntu armhf .
--
You receive
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 depe
bug still not solved, got the update to firefox-59 on lubuntu-14.04
today, it still segfaults. So I spent a few hours to an install of arch
linux on my rpi2, simply because firefox never had this issue over
there, and it still doesn't hit this bug as of today.
arch linux is rolling release, atm th
Firefox 59 fails as earlier .
Mozilla Crash Reporter:
Add-ons:
activity-stream%40mozilla.org:2018.02.17.0026-173e2795,aushelper%40mozilla.org:2.0,firefox%40getpocket.com:1.0.5,followonsearch%40mozilla.com:0.9.6,formautofill%40mozilla.org:1.0,onboarding%40mozilla.org:1.0,screenshots%40mozilla.org
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
Which is the bug id for the mentioned skia bug?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
To manage notifications about thi
firefox_57.0.4 ubuntu xenial crash like firefox 58 ubuntu xenial , before it
reach skia bug
=> 0xf4cd4790: strdr2, r3, [r1]
0xf4cd4794: ldr.w r3, [r9, #4]
0xf4cd4798: addsr3, #123; 0x7b
0xf4cd479a: beq.w 0xf4cd4a34
0xf4cd479e: ldr r1, [r6, #24]
firefox_
> 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 D
I run firefox 58.02 armhf that comes with ubuntu 16.04 and it crash in
same point my custom firefox 58.02 crashed :
Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
0xf4c3bfc4 in JS::MutableHandle::set (v=..., this=)
at
/build/firefox-ID1dFf/firefox-58.0.2+build1/obj-arm-linux-
I will install default ubuntu xenial firefox_58.0.2 and see if that crash on a
different asm instruction than my custom build and I will report .
By the way I managed to set up a cross compile development , now I compile it
with a intel cpu and is a lot faster . So a lot of testing can be made .
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
@james you said in a old post
"You can actually hexedit libxul.so and change those four vorr
instructions into NOPs. Firefox then makes it past this point but
crashes obscurely elsewhere, with different crash signatures on Firefox
58 vs 59."
Can you check where that "crashes obscurely elsewhere"
I tried yesterday java.script.enabled false in prefs.js and it still crashed ,
same crash .
i will try also javascript.options.baselinejit false ;
You know firefox 57.04 armhf , did not used sk jumper generated code
with skia disabled in prefs.js and worked fine .
I have to see if there was any
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 st
Maybe because it do not crash on skia anymore , this crash in
RootingAPI.h will be easier to fix ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L a
I installed debug symbols here are more crash about the crash , again
like i said is not in skia anymore :
Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
0xf4c3dcb4 in JS::MutableHandle::set (v=..., this=) at
/root/firefox-58.0.2+build1/obj-arm-linux-gnueabihf/dist/include/js/Ro
It successfully build a deb .I build all with gcc except gfx/skia build with
clang .
There is again a crash but It looks now is not in _sk_xor__vfp4 the asm code
where it crash is different from the asm code of _sk_xor__vfp4 .
firefox -g
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C
Thanks Chris that is hopeful to know .
As a summary for all I did and some notes :
Compiling firefox with clang was fine ,just required some -std=xxx adaption.
But after it finish to compile it try to make libxul.so by linking libs and it
fail to link libstagefright teling me it can not find 'fre
@Chituc
I don't know if this is a helpful idea, or not, but here goes.
The problems are:
1 knowledge/expertise re compiling and linking specific to Firefox (sadly I
can't help there - no experience)
2 Long compile times to iterate - you've asked if anyone has arm64 that could
help.
Re 2, would
I can not pass pass about this linking problem , because re running the
build process is very time consuming . Any way I will let it build with
gcc and I will replace in gcc build the gfx/skia dir with the one build
by clang .
--
You received this bug notification because you are a member of Ubun
When it link libxul.so it get a linker error :
1013:18.63 ../../media/libstagefright/Unified_cpp_media_libstagefright1.o: In
function `operator delete(void*)':
1013:18.64
/root/firefox-58.0.2+build1/obj-arm-linux-gnueabihf/dist/include/mozilla/mozalloc.h:230:
undefined reference to `free'
1013:
And that why gdb do not recognize it as a instruction set . We have just
to wait few for the compile to finish and I'll tell you if it really
works .It is very close to building libxul.so right now .
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
So I heve the strong feeling that here the crash in skia comes from . If
"-mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 -mthumb" is not
passed to clang/gcc , then it does not recognize that part of the
binary content as an instruction and it just displays it as if it were
a 32-bit data
Hmm very interesting . I also objdump -d SkJumper_generated.o ( build by clang
without "-mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 -mthumb" )
and is different result .
0318 <_sk_xor__vfp4>:
318: f2c70f10.word 0xf2c70f10
31c: e4913004.word
I disasm the SkJumper_generated.o generated by clang : objdump -d
SkJumper_generated.o
0318 <_sk_xor__vfp4>:
318: f2c70f10vmov.f32d16, #1 ; 0x3f80
31c: e4913004ldr r3, [r1], #4
320: f2603d83vsub.f32d19, d16, d3
Also in firefox-58.0.2+build1/obj-arm-linux-
gnueabihf/gfx/skia/backend.mk on the last line I also have added
"-mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 -mthumb" hoping
to fix the crash in skia . Will see in few hours if will still crash or
not ...
--
You received this bug notificat
Here is what I did .
apt-get install build-essential fakeroot devscripts
apt-get build-dep firefox
apt-get install icecc
apt-get install clang-5.0
apt-get install python-dev
apt-get source firefox
cd firefox-58.0.2+build1/
export CC=clang-5.0
export CXX=clang++-5.0
export CCACHE_PREFIX=icecc
Thank you for your effort! Could you please attach a patch against the
firefox source tree for the changes you made, in regards to make it
compile with clang?
If you ran out of memory during linking of libxul.so you could try to
append '-Wl,--no-keep-memory -Wl,--reduce-memory-overheads' as ldflag
The good news is that I just had to modify the "-std=" just in 4 places and all
compiled fine .
The bad one is that I received a "Memory exausted" error when it build
libxul.so .
But I upgraded the machine from 8 gb of RAM to 16 gb of RAM and in 2-3 hours it
will try again to build libxul.so .So
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
_sk_xor__vfp4 asm code is thumb2 code so maybe if gcc will be instructed
to compile it as a thumb2 code will work also to compile with gcc .
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title
Can the firefox build be instructed to build only libxul.so ? This will
be a faster compile than to build all . I was thinking to build just
that with clang and replace this inoriginal deb.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Firefox looks to dnt get compiled by clang out of the box without intervention.
I got some errors like :
87:09.20 In file included from
/root/firefox-58.0.2+build1/media/libpng/arm/filter_neon_intrinsics.c:22:
87:09.22 /usr/lib/llvm-4.0/bin/../lib/clang/4.0.0/include/arm_neon.h:433:1:
error: unk
Thanks @Cris for link , but fortunately my configure step passed and all was
fine .
It started to compile is is still compiling for 1:30 hours already .
I did not had that problem ,firefox compile but is very show .I hope will be no
errors .
Let's hope building with clang will fix that skia cras
@ Chituc
Have been googling using clang to compile firefox. This link may be of interest:
https://github.com/JanitorTechnology/dockerfiles/issues/86
see the last post, which indicates support for compiling using clang versions
3.9 through to 6.0.
I see you're using 3.8...
** Bug watch added: git
I confirm they really use clang when they build chromium and they do not cross
compile it .
So I have a strong feeling if we compile firefox with clang will work and will
be no crash .
My machine is building using clang but will take maybe 1 day to finish.
I see the firefox build for ubuntu devs
Ok , I started to compile it using clang :
0:55.76 checking for pkg_config... /usr/bin/pkg-config
0:55.80 checking for pkg-config version... 0.29.1
0:55.82 checking for yasm... /usr/bin/yasm
0:55.86 checking yasm version... 1.3.0
0:55.94 checking the target C compiler version... 3.8.0
0:56.5
armhf build of firefox 58.0.2+build1-0ubuntu1 in ubuntu bionic PROPOSED
Still crashes for me on 18.04 on raspberry pi.
Thread 1 "firefox" received signal SIGILL, Illegal instruction.
0x73b73dfa in _sk_xor__vfp4 () from /usr/lib/firefox/libxul.so
(gdb) bt
#0 0x73b73dfa in _sk_xor__vfp4 () at /usr
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 Ubuntu
My last feeling ,is it just a aarch64 kernel with a arm64 Ubuntu xenial and
enabled multiarch so it downloads the armhf build deps . Any way like you said
, maybe a build with clang will fix it .
Let;s hope there will be a way to finaly have latest firefox on armhf .
Thank you for your interest t
Also I think I'm right it is not cross compiled , you can see at the end of
build log :
+--+
| Summary |
+---
@James Donald (jdonald) thanks for your reply .All you say is very interesting
by my remark is that I think ubuntu do not cross compile firefox for armhf ,
they just use a aarch64 (arm 64 bit ) kernel and they run a armhf Ubuntu .
I 'm not the expert but from what I talked to others they said i
** Changed in: firefox (Ubuntu)
Status: Fix Released => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711337
Title:
Firefox crashes at start on armv7L after 55.0.1 update
To manag
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 th
I downloaded firefox_58.0.2+build1-0ubuntu1_armhf.deb and tried to
install but libraries in 17.10 are different
libfontconfig1 (>= 2.12) but 2.11.94-0ubuntu2
On 2/25/18, James Donald <1711...@bugs.launchpad.net> wrote:
> Thanks Chituc. That's spot-on with the identical error in Firefox.
> Spe
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
They at chromium say they use clang when they cross compile chromium .And they
had exactly same problem like firefox have ,when they build chromium native
using gcc .
You can read a irc log :
[16:17:16] This has been puzzling us for a few weeks already because
we can't get
1 - 100 of 152 matches
Mail list logo