Bug 226476
| Summary: | www/firefox: update to 60.0 | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Jan Beich <jbeich> | ||||||||||||||||||||||||||||||||
| Component: | Individual Port(s) | Assignee: | freebsd-gecko (Nobody) <gecko> | ||||||||||||||||||||||||||||||||
| Status: | Closed FIXED | ||||||||||||||||||||||||||||||||||
| Severity: | Affects Only Me | CC: | cpm, debdrup, gecko, grahamperrin, jakub_lach, jrm, lwhsu, val | ||||||||||||||||||||||||||||||||
| Priority: | --- | Keywords: | needs-qa, patch | ||||||||||||||||||||||||||||||||
| Version: | Latest | Flags: | bugzilla:
maintainer-feedback?
(gecko) |
||||||||||||||||||||||||||||||||
| Hardware: | Any | ||||||||||||||||||||||||||||||||||
| OS: | Any | ||||||||||||||||||||||||||||||||||
| URL: | https://wiki.mozilla.org/Releases/Firefox_60/Test_Plan | ||||||||||||||||||||||||||||||||||
| Bug Depends on: | 223425, 225627 | ||||||||||||||||||||||||||||||||||
| Bug Blocks: | 227850 | ||||||||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||||||||
|
Description
Jan Beich
2018-03-09 15:04:41 UTC
In Chromium, it has been the other way around; now WebRTC is required by default to compile Chromium. Unfortunately, WebRTC is not fully supported on FreeBSD. Created attachment 191460 [details]
beta3
Created attachment 191546 [details]
beta4
Created attachment 191556 [details]
bsd.gecko.mk-sndio.diff
Hi,
60.0b4 fails to patch with SNDIO=on because webrtc has moved a little
bit in the tree.
Patching webrtc doesn't seem to be necessary anymore so guarding it
for older Gecko versions (like we did with the cubeb tests a while ago)
should be enough to workaround this.
I built Waterfox and Firefox 60.0b4 with the attached patch and
everything seems to work ok as before. Can you include it in the
update?
Comment on attachment 191556 [details]
bsd.gecko.mk-sndio.diff
The patch is needed for a Pale Moon update as well when building with SNDIO=on
since they completely removed WebRTC code in 27.8.0. Ok to land it now?
Comment on attachment 191556 [details]
bsd.gecko.mk-sndio.diff
Looks OK.
"if...fi" block can have more than one command or none at all (e.g., "if true; false; then else fi") terminated by either newline or semicolon. By terminating a command on the same line as "fi" you're making it harder to append another command within the conditionals.
A commit references this bug: Author: tobik Date: Mon Mar 19 05:46:03 UTC 2018 New revision: 464981 URL: https://svnweb.freebsd.org/changeset/ports/464981 Log: Fix post-patch-SNDIO-on in preparation of updates to www/firefox 60.0 and to www/palemoon 27.8.1 Some patches no longer apply to them. WebRTC has moved paths in Firefox 60.0 and no longer needs to be patched. Pale Moon removed WebRTC completely in 27.8.0. PR: 226476 Approved by: gecko (jbeich) Changes: head/Mk/bsd.gecko.mk Created attachment 191654 [details]
beta5
WebRTC is back on track with Landry's help. Unfortunately, I haven't found time to rebase libv4l patch.
(In reply to Jan Beich from comment #8) beta5 builds fine and also mostly runs ok, however when I try to print something it takes forever for the print preview window to actually show up and the UI completely freezes up. Hmm, this also happens with Firefox 59.0.1,1 with default options, so I guess it's nothing new. (In reply to Tobias Kortkamp from comment #9) It happened because I had the sysctl net.inet.tcp.blackhole=2 set. Setting it back to 0 fixes this. Created attachment 191746 [details] beta6 (crashes on i386) https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-03-19&enddate=2018-03-23 And https://bugzilla.mozilla.org/show_bug.cgi?id=1436911 as a "pkg upgrade" crashfix i386 issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1448189 Created attachment 191780 [details]
beta6 (rebased after r465446)
Created attachment 191860 [details] beta7 https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-03-23&enddate=2018-03-27 Can someone build the binary package(s) for beta7 or (tonight) for beta8? A user contacted me privately offering to help testing Firefox 60 but lacks powerful enough hardware to build the port. Bug 222225 comment 17 describes why I can't. (In reply to Jan Beich from comment #14) Package for stable or current? Ah, my apologies. I somehow completely missed finding this bug when searching for it. I'm on 11.1-RELEASE, so I imagine -STABLE should do it? Assuming amd64? Should've probably just included uname -a from the start: FreeBSD nerd-thinkpad.local 11.1-RELEASE-p8 FreeBSD 11.1-RELEASE-p8 #0: Tue Mar 13 17:07:05 UTC 2018 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Created attachment 191963 [details] beta8 (rebased against ports r465943) https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-03-27&enddate=2018-03-30 Created attachment 192155 [details] beta9 (rebased after ports r466270) https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-03-30&enddate=2018-04-03 Created attachment 192238 [details] beta10 (rebased after ports r466432) https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-04-03&enddate=2018-04-05 So, there's no chance of having someone build it? Although I see that v4l is getting dropped for lack of time, so webcam support is gonna break anyhow, it seems.. Wish I had the talent or money to do something about that, but I don't. Not v4l but libv4l. Only useful if a webcam doesn't support v4l2 or one of WebRTC video formats[1]. Contributed by someone who had JPEG-only camera but, looking at the code, libv4l should no longer be necessary. [1] https://searchfox.org/mozilla-central/rev/d0413b711da4/media/webrtc/trunk/webrtc/modules/video_capture/linux/video_capture_linux.cc#222-230 [2] https://chromium.googlesource.com/external/webrtc/+/6b6eb44cca%5E!/ b10 builds successfully here with the options below: http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2018-04-08_08h09m26s/logs/firefox-60.0.b10,1.log % poudriere options -j 11amd64 -sn www/firefox [00:00:00] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf ===> The following configuration options are available for firefox-60.0.b10,1: CANBERRA=off: Sound theme alerts DBUS=off: D-Bus IPC system support DEBUG=off: Build with debugging support DTRACE=on: Build with DTrace probes FFMPEG=on: FFmpeg support (WMA, AIFF, AC3, APE...) GCONF=off: GConf configuration backend support INTEGER_SAMPLES=off: Integer audio sample format LIBPROXY=off: Proxy support via libproxy OPTIMIZED_CFLAGS=on: Use extra compiler optimizations PROFILE=off: Build with profiling support TEST=off: Build and/or run tests ====> Options available for the multi AUDIO: you have to choose at least one of them ALSA=off: ALSA audio architecture support JACK=off: JACK audio server support PULSEAUDIO=off: PulseAudio sound server support SNDIO=on: Sndio audio support I will also test with default options and report back. Looks good with default options: http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2018-04-08_08h44m27s/logs/firefox-60.0.b10,1.log Since my webcam feed isn't showing up in Firefox 60 beta10 with default options, despite the fact that it works in Firefox 58 (from the official packages), I decided to try enabling debug options. However, even with MAKE_UNSAFE_JOBS=yes, I get the error shown on [1] while running make package with the debug option enabled on a system with FreeBSD 11.1-STABLE r330643 according to uname -a. [1] http://termbin.com/43yi I neither own a microphone or web camera nor smart enough to emulate those in order to help investigate WebRTC issues. (In reply to D. Ebdrup from comment #26) > my webcam feed isn't showing up Maybe check IPC limits. For one, OpenBSD has smaller kern.shminfo.shmall default than kern.ipc.shmall on FreeBSD which breaks screen capture. > it works in Firefox 58 DEBUG build or logging[1] won't help much unless you know what to look for. mozregression isn't usable on Tier3 platforms like FreeBSD (no upstream builds, flo@'s buildbot is down for months), so try bisecting source instead. Here's how to build Firefox outside of ports: $ pkg install python27 binutils $ hash git 2>/dev/null || pkg install mercurial $ hg clone https://hg.mozilla.org/mozilla-unified firefox || git clone https://github.com/mozilla/gecko-dev firefox $ cd firefox $ hg update release || git checkout origin/release $ echo "export COMPILER_PATH=/usr/local/bin" >>.mozconfig $ echo "ac_add_options --disable-debug-symbols" >>.mozconfig $ ./mach bootstrap # select Firefox for Desktop $ ./mach build $ ./mach run https://mozilla.github.io/webrtc-landing/ [1] https://wiki.mozilla.org/Media/WebRTC/Logging > ../../build/unix/gold/ld: error: /usr/ports/www/firefox/work/.build/toolkit/library/../../js/src/js-dtrace.o: unexpected reloc 8 in object file > /usr/ports/www/firefox/work/.build/toolkit/library/../../js/src/js-dtrace.o:/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common/drti.c:__SUNW_dof: > error: unexpected reloc 8 in object file > c++: error: linker command failed with exit code 1 (use -v to see invocation) Disable DTRACE option and try again. Created attachment 192374 [details] beta11 (rebased after ports r466648) https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-04-05&enddate=2018-04-10 (In reply to Jan Beich from comment #27) >OpenBSD But I'm using FreeBSD, so I don't see how that's relevant. Still, I've upped kern.ipc.shmall to 262k instead of the 131k it was at - so whatever limits there may be shouldn't be a problem. >Logging I'll try messing around with it anyhow - with pkg, it's remarkably easy to switch between the working and non-working version of Firefox, so I should be able to tell if it reports anything different, and possibly find out what that means. >Disable DTRACE option The thing is, I only get the dtrace errors if the DEBUG option is turned on. The first package that I built, and that I'm using to test with, is built with default options and didn't get any errors. Long of the short of it is - Don't feel you have to delay the port on my account, though - if I need webrtc, I'll install the working version temporarily, no reason to have that delay a new version of the port going out. If I find a real bug in FreeBSDs port, or better yet a fix, I'll file a separate report. Created attachment 192488 [details] beta12 https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-04-10&enddate=2018-04-13 Created attachment 192576 [details] beta13 (rebased after ports r467551) https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-04-13&enddate=2018-04-17 beta13 works for me (12.0-CURRENT r332357). I tested some demoes on https://webrtc.github.io/samples/ and look good to me. Sadly, Google Handouts still doesn't work. Created attachment 192684 [details] beta14 https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-04-17&enddate=2018-04-20 Comment on attachment 192684 [details] beta14 Time to move the patch to Phabricator. Bugzilla support for interdiffs is poor and it doesn't allow patches larger than 1 Mb. Firefox 60 enables WebAuthn by default with Google Accounts support. Greg V implemented FreeBSD support, so I've integrated it into the patch. https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg24759.html https://github.com/jcjones/u2f-hid-rs/pull/62 Patch: https://reviews.freebsd.org/D15186?download=true Changes (since beta14): https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-04-20&enddate=2018-04-24 A commit references this bug: Author: jbeich Date: Tue May 1 00:51:38 UTC 2018 New revision: 468751 URL: https://svnweb.freebsd.org/changeset/ports/468751 Log: www/firefox: update to 60.0 - Add U2F support, required by Web Authentication [1] - Drop libv4l support to reduce maintenance Changes: https://www.mozilla.org/firefox/60.0/releasenotes/ PR: 226476 Tested by: tobik, jrm, D. Ebdrup, lwhsu Submitted by: Greg V [1] Security: 5aefc41e-d304-4ec8-8c82-824f84f08244 MFH: 2018Q2 Differential Revision: https://reviews.freebsd.org/D15186 Changes: head/Mk/Uses/gecko.mk head/Mk/bsd.gecko.mk head/www/firefox/Makefile head/www/firefox/distinfo head/www/firefox/files/patch-bug1021761 head/www/firefox/files/patch-bug1433747 head/www/firefox/files/patch-bug1438678 head/www/firefox/files/patch-bug1444083 head/www/firefox/files/patch-bug1444798 head/www/firefox/files/patch-bug1447925 head/www/firefox/files/patch-bug1452041 head/www/firefox/files/patch-bug826985 head/www/firefox/files/patch-u2f-hid-rs62 head/www/firefox/files/patch-z-bug1436911 head/www/firefox/files/patch-z-bug517422 head/www/firefox/pkg-message head/www/firefox-i18n/Makefile head/www/firefox-i18n/Makefile.lang head/www/firefox-i18n/Makefile.option head/www/firefox-i18n/distinfo 60 rollout has started, ahead of upstream because our QA is different. www/firefox-i18n is still at beta16 due to a hiccup on Mozilla infra[1] but it should work fine with rc1. [1] https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=9ef500ce24aa I've lost l18n in xterm/firefox after upgrade to firefox 60. I wonder what has happened in that timeframe? (In reply to jakub_lach from comment #37) ^ that was recent xkbcomp update A commit references this bug: Author: jbeich Date: Thu May 3 20:41:54 UTC 2018 New revision: 468985 URL: https://svnweb.freebsd.org/changeset/ports/468985 Log: www/firefox: switch to rc2 Changes: https://hg.mozilla.org/releases/mozilla-release/pushloghtml?startdate=2018-05-01&enddate=2018-05-04 PR: 226476 Changes: head/www/firefox/Makefile head/www/firefox/distinfo head/www/firefox-i18n/Makefile head/www/firefox-i18n/distinfo 60.0,1 looking good to me, thanks. I know that's not much, but since Firefox 60 introduction to www/firefox, it was nothing but multiple coredumps daily, something I have not seen for a very long time. May 5 16:05:18 Thinkpad kernel: pid 750 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:05:21 Thinkpad kernel: pid 752 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:05:24 Thinkpad kernel: pid 755 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:05:26 Thinkpad kernel: pid 754 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:05:30 Thinkpad kernel: pid 753 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:08:40 Thinkpad kernel: pid 765 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:08:42 Thinkpad kernel: pid 769 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:08:45 Thinkpad kernel: pid 767 (firefox), uid 1001: exited on signal 11 (core dumped) May 5 16:08:46 Thinkpad kernel: pid 773 (firefox), uid 1001: exited on signal 11 (core dumped) I would go to ESR, but unfortunately, my .mozilla profile is too far removed from it already. (In reply to jakub_lach from comment #41) As in "not much" details to help troubleshooting? Get a backtrace, try the binary package, try in a jail or different machine, try a fresh profile, try to disable e10s, find another user with the same issue. I don't see crashes on FreeBSD 10.4 i386. Mozilla doesn't test on FreeBSD at all and there's no automated crash reporting or telemetry to fall back on. Hoping the issue would disappear on its own by release announcement is often pointless. Otherwise, even Nightly on FreeBSD is stable enough for daily usage sans occasional bustage. (In reply to jakub_lach from comment #42) > May 5 16:05:18 Thinkpad kernel: pid 750 (firefox), uid 1001: exited on signal 11 (core dumped) > May 5 16:05:21 Thinkpad kernel: pid 752 (firefox), uid 1001: exited on signal 11 (core dumped) > May 5 16:05:24 Thinkpad kernel: pid 755 (firefox), uid 1001: exited on signal 11 (core dumped) Only content processes crash? Does it happen on every site or those that contain certain (e.g., audio/video) elements? If the latter make sure firefox dependencies are also up to date: ffmpeg, libvpx, harfbuzz, etc. Yes, as in "not much" in terms of troubleshooting. The profile was remade from scratch a month or so ago. If I get something more substantial, I will get back to you. It's a 11-STABLE amd64, ports are up do date. (In reply to jakub_lach from comment #45) What do I now know, - premade binary package crashes too - fresh profile also What triggers it? Can't point a finger, but multiple YouTube videos (50+) and closing a Firefox is a good bet (cannot exit cleanly, that was a fresh profile and a package from ports). Sometime it's only a single tab and it does not take whole Firefox down, but both kinds really. Last time I needed bt from Firefox (a few years ago) I remember I needed to turn DEBUG on a lot of things (it was gstreamer iirc and it went away by itself). > 60.0,1 looking good to me, thanks. More specifically: - 60.0,1 - e10s enabled - HP EliteBook 8570p with 16 GB memory, <https://wiki.freebsd.org/Laptops/HP_EliteBook_8570p> - FreeBSD-CURRENT, $ uname -v FreeBSD 12.0-CURRENT #0 r333193: Thu May 3 10:59:06 BST 2018 root@momh167-gjp4-hpelitebook8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC ---- I pushed harder. e10s disabled (browser.tabs.remote.force-disable), to tell whether the app would crash. 1,245 tabs across fifteen windows, restored with Session Boss: OK. Then I browsed to a few other tabs, and quit. The same number of tabs, restored with the History menu: OK. An after effect of using Session Boss: if restoration is performed without Session Boss, then it may be necessary to manually load tabs. Disabled Session Boss, enabled Tab Session Manager, saved the session, quit. The same number, restored with Tab Session Manager: OK. Some restored tabs become blank when activated, re: <https://github.com/sienori/Tab-Session-Manager/issues/238> (not an issue with Tab Session Manager) it's an after-effect of using Session Boss: re: Added Tip Tab <https://addons.mozilla.org/addon/tip-tab/>, disabled Tab Session Manager, re-enabled Session Boss, re-enabled e10s, quit. The same number, restored with Session Boss: in progress. I'll revisit later, use Tip Tab to load some (restored) YouTube tabs. > … disabled Tab Session Manager, > re-enabled Session Boss, > re-enabled e10s, quit. … I forgot to re-enable e10s. > The same number, restored with Session Boss: … – was OK. > … use Tip Tab to load some (restored) YouTube tabs. Within the restored session I found (with Tip Tab) and loaded three YouTube videos. At some point during the session – maybe whilst the three videos played concurrently – there was, in response to a click on (or load of) a tab, _momentary_ appearance of a content process. The momentary multi-process surprised me, but I don't know whether it's a bug: - is it _ever_ appropriate to have more than one process when browser.tabs.remote.force-disable is true? I guess that Mozilla may invalidate any bug report that involves browser.tabs.remote.force-disable with Firefox Quantum. Jan, any thoughts? Would you like this spun off to a separate bug report in either the Mozilla or FreeBSD area? TIA A commit references this bug: Author: jbeich Date: Mon May 7 20:33:24 UTC 2018 New revision: 469334 URL: https://svnweb.freebsd.org/changeset/ports/469334 Log: MFH: r468751 r468754 r468985 r469332 www/firefox: update to 60.0 - Add U2F support, required by Web Authentication [1] - Drop libv4l support to reduce maintenance Changes: https://www.mozilla.org/firefox/60.0/releasenotes/ PR: 226476 Tested by: tobik, jrm, D. Ebdrup, lwhsu Submitted by: Greg V [1] Security: 5aefc41e-d304-4ec8-8c82-824f84f08244 Approved by: ports-secteam blanket Differential Revision: https://reviews.freebsd.org/D15186 Changes: _U branches/2018Q2/ branches/2018Q2/Mk/Uses/gecko.mk branches/2018Q2/Mk/bsd.gecko.mk branches/2018Q2/www/firefox/Makefile branches/2018Q2/www/firefox/distinfo branches/2018Q2/www/firefox/files/patch-bug1021761 branches/2018Q2/www/firefox/files/patch-bug1375074 branches/2018Q2/www/firefox/files/patch-bug1433747 branches/2018Q2/www/firefox/files/patch-bug1438678 branches/2018Q2/www/firefox/files/patch-bug1442583 branches/2018Q2/www/firefox/files/patch-bug1444083 branches/2018Q2/www/firefox/files/patch-bug1444798 branches/2018Q2/www/firefox/files/patch-bug1445907 branches/2018Q2/www/firefox/files/patch-bug1447359 branches/2018Q2/www/firefox/files/patch-bug1447925 branches/2018Q2/www/firefox/files/patch-bug1451292 branches/2018Q2/www/firefox/files/patch-bug1452041 branches/2018Q2/www/firefox/files/patch-bug1456556 branches/2018Q2/www/firefox/files/patch-bug826985 branches/2018Q2/www/firefox/files/patch-u2f-hid-rs62 branches/2018Q2/www/firefox/files/patch-z-bug1436911 branches/2018Q2/www/firefox/files/patch-z-bug517422 branches/2018Q2/www/firefox/pkg-message branches/2018Q2/www/firefox-i18n/Makefile branches/2018Q2/www/firefox-i18n/Makefile.lang branches/2018Q2/www/firefox-i18n/Makefile.option branches/2018Q2/www/firefox-i18n/distinfo rc2 became release: https://hg.mozilla.org/releases/mozilla-release/rev/3202d5534730 (In reply to jakub_lach from comment #46) Can you try removing files/patch-bug1438678 and files/patch-z-bug1436911 ? Those improve how child processes are initialized and, normally, should've been part of 61.0. Did you toggle any prefs in about:config? In particular, gfx.xrender.enabled=true or layers.acceleration.force-enabled=true may degrade stability. Can you check about:support what audio backend is used? There's no perfect one, each has issues. (In reply to Graham Perrin from comment #48) > Would you like this spun off to a separate bug report in > either the Mozilla or FreeBSD area? Try bug 227850 then check on Linux and macOS. FreeBSD uses posix_spawn (like macOS) to create child processes. It wouldn't hurt to file a bug on Mozilla tracker but "_momentary_ appearance of a content process" may be a normal behavior given Firefox keeps the number of content processes limited (unlike Chromium). A commit references this bug: Author: jbeich Date: Wed May 9 20:32:25 UTC 2018 New revision: 469467 URL: https://svnweb.freebsd.org/changeset/ports/469467 Log: security/vuxml: mark firefox < 60 as vulnerable PR: 226476 Changes: head/security/vuxml/vuln.xml (In reply to Jan Beich from comment #50) > Can you try removing files/patch-bug1438678 and files/patch-z-bug1436911 ? Recompiling without now. I have long streaks of stable use and long streaks of coredumps, still cannot isolate the cause precisely. >Did you toggle any prefs in about:config? In particular, >gfx.xrender.enabled=true or layers.acceleration.force-enabled=true may degrade >stability. No, I did most of my testing with my daily profile, but neither that nor fresh clean profile (which I've also crashed) has that set. >Can you check about:support what audio backend is used? Alsa Thanks for your attention :) (In reply to jakub_lach from comment #52) > Can you try removing files/patch-bug1438678 and files/patch-z-bug1436911 ? Crashed version compiled without these too, albeit just once. I'll try to provide bt once I've recompile with debug. 86_64-unknown-freebsd/debug/libgkrust.a(std-618faf8e489f63eb.std4-60b51645c042d75ec977e9128499131e.rs.rcgu.o):std4-60b51645c042d75ec977e9128499131e.rs:function std::sys::unix::process::process_inner::<impl std::sys::unix::process::process_common::Command>::do_exec: warning: undefined reference to 'environ' c++: error: unable to execute command: Bus error (core dumped) c++: error: linker command failed due to signal (use -v to see invocation) gmake[5]: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/rules.mk:701: libxul.so] Error 254 gmake[5]: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build/toolkit/library' gmake[4]: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/recurse.mk:73: toolkit/library/target] Error 2 gmake[4]: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build' gmake[3]: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/recurse.mk:33: compile] Error 2 gmake[3]: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build' gmake[2]: *** [/usr/obj/usr/ports/www/firefox/work/firefox-60.0/config/rules.mk:434: all] Error 2 gmake[2]: Leaving directory '/usr/obj/usr/ports/www/firefox/work/.build' ===> Compilation failed unexpectedly. Unfortunately linker failed in DEBUG, FreeBSD 11.2-PRERELEASE #0 r333148 amd64, all options unchecked beside FFMPEG, DEBUG, OPTIMIZED, ALSA --enable-debug enables assertions, runtime checks and disables optimizations. None of which have been tested on FreeBSD. For gdb/lldb only debug symbols and frame pointer are required e.g., $ env CFLAGS=-g make clean all STRIP= WITHOUT="DEBUG DTRACE OPTIMIZED_CFLAGS" -C /usr/ports/www/firefox or $ make clean all WITH_DEBUG= WITHOUT="DEBUG DTRACE OPTIMIZED_CFLAGS" -C /usr/ports/www/firefox OPTIMIZED_CFLAGS passes -fomit-frame-pointer unless DEBUG, DTRACE or PROFILE are enabled. (In reply to Jan Beich from comment #55) > $ make clean all WITH_DEBUG= WITHOUT="DEBUG DTRACE OPTIMIZED_CFLAGS" -C /usr/ports/www/firefox During linking unfortunately ld went pfault and ate 8GB of RAM and 4GB of swap, looked hopeless, so I've terminated it. (In reply to jakub_lach from comment #57) Try building firefox with non-debug symbols and frame pointer. Get a backtrace then rebuild the affected functions with debug symbols. If backtrace looks corrupted or incomplete rebuild every library dependency with debug symbols, including libc/libthr/rtld. A commit references this bug: Author: jbeich Date: Wed May 16 22:17:01 UTC 2018 New revision: 470155 URL: https://svnweb.freebsd.org/changeset/ports/470155 Log: www/firefox: update to 60.0.1 Changes: https://www.mozilla.org/firefox/60.0.1/releasenotes/ PR: 226476 Changes: head/www/firefox/Makefile head/www/firefox/distinfo head/www/firefox-i18n/Makefile head/www/firefox-i18n/distinfo A commit references this bug: Author: jbeich Date: Wed May 16 22:19:47 UTC 2018 New revision: 470156 URL: https://svnweb.freebsd.org/changeset/ports/470156 Log: MFH: r470155 www/firefox: update to 60.0.1 Changes: https://www.mozilla.org/firefox/60.0.1/releasenotes/ PR: 226476 Approved by: ports-secteam blanket Changes: _U branches/2018Q2/ branches/2018Q2/www/firefox/Makefile branches/2018Q2/www/firefox/distinfo branches/2018Q2/www/firefox-i18n/Makefile branches/2018Q2/www/firefox-i18n/distinfo (In reply to Li-Wen Hsu from comment #32) > Sadly, Google Handouts still doesn't work. Can you try again? https://old.reddit.com/r/firefox/comments/8leqgb/firefox_is_now_supported_by_google_hangouts_and/ A commit references this bug: Author: jbeich Date: Wed Jun 6 18:18:58 UTC 2018 New revision: 471865 URL: https://svnweb.freebsd.org/changeset/ports/471865 Log: www/firefox: update to 60.0.2 Changes: https://www.mozilla.org/firefox/60.0.2/releasenotes/ PR: 226476 Changes: head/www/firefox/Makefile head/www/firefox/distinfo head/www/firefox-i18n/Makefile head/www/firefox-i18n/distinfo A commit references this bug: Author: jbeich Date: Wed Jun 6 18:26:06 UTC 2018 New revision: 471869 URL: https://svnweb.freebsd.org/changeset/ports/471869 Log: MFH: r471865 www/firefox: update to 60.0.2 Changes: https://www.mozilla.org/firefox/60.0.2/releasenotes/ PR: 226476 Approved by: ports-secteam blanket Changes: _U branches/2018Q2/ branches/2018Q2/www/firefox/Makefile branches/2018Q2/www/firefox/distinfo branches/2018Q2/www/firefox-i18n/Makefile branches/2018Q2/www/firefox-i18n/distinfo (In reply to jakub_lach from comment #41) It looks like those finally ceased after clang update to 6. (In reply to jakub_lach from comment #64) More likely bug 181741. Clang-related crashes are usually easier to reproduce. |