After updating www/firefox from ports to version 123.0, I'm getting the following error while starting it: XPCOMGlueLoad error for file /usr/local/lib/firefox/libgkcodecs.so: /usr/local/lib/firefox/libgkcodecs.so: Undefined symbol "sin" Couldn't load XPCOM. My box is running 13.3-STABLE.
Work fine for me on 13.2-p9 amd64 with build options: ALSA : off CANBERRA : off DBUS : off DEBUG : off FFMPEG : on JACK : off LIBPROXY : on LTO : off OPTIMIZED_CFLAGS: on PROFILE : off PULSEAUDIO : off SNDIO : off TEST : off Port was updated today to 123.0 rc2 - check it too.
Hi Port was updated today to 123.0 rc2 - check it too. Have build it via synth. Same result and error as reported by Ale. So not fixed by RC2 Running 14-STABLE
If it is options I have built with: ALSA : off CANBERRA : off DBUS : on DEBUG : off FFMPEG : on JACK : off LIBPROXY : on LTO : off OPTIMIZED_CFLAGS: on PROFILE : on PULSEAUDIO : on SNDIO : off TEST : off
Hi again Tried to build with your options (except enabling pulseaudio) and it is not lauching. So reinsatlled from prebuilt once again.
13.2 - llvm 14 13.3 - llvm 17 13-STABLE - llvm 17 14.0 - llvm 16 14-STABLE - llvm 17 Do you have 13.2 and/or 14.0 for test? Or maybe you can build firefox for 13.2 and run on your current system?
I am on 14 STABLE.
I'm getting the same error with rc2 (firefox-123.0_1,2). $ make showconfig -C /usr/ports/www/firefox ===> The following configuration options are available for firefox-123.0_1,2: CANBERRA=off: Sound theme alerts DBUS=on: D-Bus IPC system support DEBUG=off: Build with debugging support FFMPEG=on: FFmpeg support (WMA, AIFF, AC3, APE...) LIBPROXY=off: Proxy support via libproxy LTO=off: Use Link-Time Optimization OPTIMIZED_CFLAGS=on: Use extra compiler optimizations PROFILE=on: Build with profiling support TEST=off: Build and/or run tests ====> Extra cubeb audio backends (OSS is always available) ALSA=off: ALSA audio architecture support JACK=off: JACK audio server support PULSEAUDIO=off: PulseAudio sound server support SNDIO=on: Sndio audio support ===> Use 'make config' to modify these settings $ uname -vmK FreeBSD 13.3-STABLE 2e009b460 STARLESS amd64 1303500
Hello, Same problem here. I would appreciate if we would somewhat ease on rapid updates with rcs, as they force me to recompile and they still do not work (no need for esr here, just would prefer to not recompile something that does not work, if it is possible). I had to use mobile to reply to this prans type it manually. firefox-123.0_1,2 14.0-STABLE stable/14-fad23b1a2 www/firefox all options off beside - FFMPEG OPTIMIZED_CFLAGS PROFILE
"Looks like a missing -lm to me." was mentioned on the ports mailing list. Meanwhile, I'm using this workaround: $ LD_PRELOAD=/lib/libm.so.5 firefox
(In reply to Stefan Ehmann from comment #9) Makes sense, thanks.
(In reply to Stefan Ehmann from comment #9) I was thinking the same about the missing -lm. I think that some stuff in /etc/make.conf could be messing the compiler flags order for this version, or something like that. In fact, after some tests I've found that commenting "CPUTYPE?=..." and rebuilding the port firefox starts without errors...I'm writing this comment on 123. Lars, Jakub, do you also have CPUTYPE set in /etc/make.conf? Or maybe some custom CFLAGS?
Having that problem on 15-8758bf0aaec1 aarch64 but not in 15-4594eb454891 amd64 with poudriere jails matching host and using stricly pkgs. Isn't it supposed to fail on amd64 too?
Yes. I have set CPUTYPE to alderlake. And to me that is the whole point of building packages. Together with a few flags for packages. It makes my system quite a lot snappier than otherwise.
(In reply to Ale from comment #11) Yes, I have CPUTYPE?=penryn among other port specific things (amd64).
As I've found here before I started building 123, I've added LDFLAGS+= -lm line after CFLAGS_powerpc64le= -DSQLITE_BYTEORDER=1234 line in www/firefox/Makefile and firefox starts fine. I have .if !${.CURDIR:M/usr/src/sys/boot*} CPUTYPE?= haswell .endif in my /etc/Make.conf. Anyway, if prepending "LD_PRELOAD=/lib/libm.so.5" is required, adding -lm in CFLAGS and/or CXXFLAGS would not be needed, adding to LDFLAGS is sufficient. Not sure why libm is needed to pull in but not needed for maintainer (if bitten, the maintainer would add this somewhere in www/firefox/Makefile or Mk/bsd.gecko.mk). I preferred to modify www/firefox/Makefile, as modifying Mk/bsd.gecko.mk could unwantedly affect other ports using it.
(In reply to Stefan Ehmann from comment #9) > "Looks like a missing -lm to me." was mentioned on the ports mailing list. That was me :) I'm also experiencing this on amd64, using head from a few weeks ago (I'm going to recompile base shortly, but I don't think that makes much difference). I tested some options permutations with no change. I've "fixed" it locally by adding LDFLAGS="-lm" to the port (also suggested in comment #15). I also noticed this line in firefox configure output: js/src> checking for sin in -lm... yes which could be related. Also looking at the build log I do see "-lm" being added to some targets, but not others, so this could be upstream having optimized his build to exclude the flag where deemed unnecessary, and maybe removed a little too much.
(In reply to Guido Falsi from comment #16) > I also noticed this line in firefox configure output: > js/src> checking for sin in -lm... yes I see same check on my log where firefox is affected.
But it work fine on 13.2 with CPUTYPE?=core2.
(In reply to Vladimir Druzenko from comment #18) I have an hunch this is triggered by something in the order in which ports/packages have been built/installed/updated (or not updated by poudriere). That could explain why some people are seeing this and others not with no apparent relation to other system details. It can be a pain to actually track down. I'm guessing but could be something being used during the build that has changed. I agree that adding LDFLAGS=-lm blindly to the official tree is not a good idea. We need to understand why it is needed before doing that.
As firefox is a complexed software, is there any possibility that this problem depends on profiles? Means that if some specific options are enabled (regardless it's the defaut or not), libm is required, otherwise not required. If this assumption is true, libm should be blindly linked.
(In reply to Tomoaki AOKI from comment #20) As you can see above, some of did rebuild yesterday with different options. Without success. So that is afaik no the problem
(In reply to Lars Henrik Ørn from comment #21) I didn't mean "build options", but something with "about:config" and/or settings menu. These can be changed at run time (some would require restarting firefox, though), so if any of these affect, libm should be unconditionally linked.
Has anyone else with the same problem + CPUTYPE... in /etc/make.conf tried to rebuild the port after commenting the CPUTYPE... line? For me that solved the problem. Searching for "-lm" in the configure output of the not woking build I've found the same line reported by Guido and also another one ("checking MOZ_LIBVPX_LIBS... -L/usr/local/lib -lvpx -lm"). Searching for libgkcodecs.so in the build output of both a working and not working build, I've found the same lines with/without "-march=...", anyway "-lm" is always there.
(In reply to Tomoaki AOKI from comment #22) I don't think that can be possible. The failure happens during startup, while ld is doing the dynamic linking. Not even a single line of code from firefox has ran. (In reply to Ale from comment #23) While I can't exclude it beforehand, it looks improbable that -march flags have such an effect, and maybe it is something else that has changed due to the rebuild. The fact the adding LDFLAGS=-lm "fixes" it makes me doubtful the -lm option is already present in the failing builds, or maybe it is an indirect dependency. Could someone with a broken binary handy post the output of "ldd -a /usr/local/lib/firefox/libgkcodecs.so"? (can't do it right now, due to my build machine being busy with other compilations)
(In reply to Guido Falsi from comment #24) ldd -a /usr/local/lib/firefox/libgkcodecs.so /usr/local/lib/firefox/libgkcodecs.so: libthr.so.3 => /lib/libthr.so.3 (0xa324f6e6000) libc.so.7 => /lib/libc.so.7 (0xa325123d000) /lib/libthr.so.3: libc.so.7 => /lib/libc.so.7 (0xa325123d000)
(In reply to Nuno Teixeira from comment #25) $ ldd -a /usr/local/lib/firefox/libgkcodecs.so /usr/local/lib/firefox/libgkcodecs.so: libthr.so.3 => /lib/libthr.so.3 (0x299200289000) libc.so.7 => /lib/libc.so.7 (0x2992015c5000) /lib/libthr.so.3: libc.so.7 => /lib/libc.so.7 (0x2992015c5000) [preloaded] [vdso] (0x2991feb67000) (currently using $ LD_PRELOAD=/lib/libm.so.5 firefox)
The fact that libm.so is not showing in both outputs tells me there is no way the -lm option was passed to the linker at build time. But I have no idea how to firefox build system works, so I'm not sure how to investigate that.
Having a look at firefox sources I found something interesting in `third_party/libwebrtc/moz-patch-stack/0106.patch`: ------ From: Chun-Min Chang <chun.m.chang@gmail.com> Date: Tue, 5 Dec 2023 20:08:00 +0000 Subject: Bug 1864008 - Move libvpx to libgkcodecs, part 2 r=webrtc-reviewers,padenot,mjf This patch addes trampoline headers for libvpx. To follow the libwebrtc merge procedure, the vpx headers are silently replaced with "trampoline" headers, which do nothing but include real VPX headers. This makes the libwebrtc-merge process easier without worrying headers' paths. On the other hand, the `rtc_build_libvpx` is set to `true` in webrtc.gni, so moz.build file for third_party/libvpx can be generated by the gn_processor in the next patch. Differential Revision: https://phabricator.services.mozilla.com/D195495 Mercurial Revision: https://hg.mozilla.org/mozilla-central/rev/d43978d3d8356e176fac2ad18f328871f36698ce ------ This has a recent date, and looks related. Makes me think libgkcodecs.so is a recent additions and upstream simply omitted the -lm there.
(In reply to Guido Falsi from comment #28) Maybe the right place to look at is `toolkit/library/moz.build` But I really don't know. Someone that has at least an idea of how firefox build system works needs to take a look at how the libgkcodecs was added. It is just glue for the multimedia codecs. I suspect at some point a library requiring -lm was merged in it causing this issue for us, due to -lm not being added to the command line to link this library.
--- config/external/gkcodecs/moz.build.orig 2024-02-14 16:08:26.414136000 +0100 +++ config/external/gkcodecs/moz.build 2024-02-14 16:09:57.723183000 +0100 @@ -16,3 +16,7 @@ SYMBOLS_FILE = "gkcodecs.symbols" if CONFIG["MOZ_SYSTEM_LIBVPX"]: DEFINES["MOZ_SYSTEM_LIBVPX"] = True +OS_LIBS += [ + 'lm' +] This migth help as a file in files, but I still have to reproduce the problem on 14.0
(In reply to Jesper Schmitz Mouridsen from comment #30) I was thinking about something along these lines, but I have no idea if this is the correct solution.
(In reply to Jesper Schmitz Mouridsen from comment #30) Adding OS_LIBS += ["-lm"] fixed the problem for me on 14.0/amd64. I have CPUTYPE set in make.conf
Found below within official ports patch as [1]. Which expression is correct? "lm"? "-lm"? or "m"? Or all workes samely? I'm confused now. --- third_party/sqlite3/src/moz.build.old 2021-08-09 16:08:59.381182000 -0500 +++ third_party/sqlite3/src/moz.build 2021-08-09 16:10:25.370954000 -0500 @@ -92,7 +92,8 @@ # Enabling sqlite math functions DEFINES['SQLITE_ENABLE_MATH_FUNCTIONS'] = True -if CONFIG["OS_TARGET"] == "Linux" or CONFIG["OS_TARGET"] == "Android": +if CONFIG["OS_TARGET"] == "Linux" or CONFIG["OS_TARGET"] == "Android" or \ + CONFIG["OS_TARGET"] == "FreeBSD": OS_LIBS += [ "m" ] [1] https://cgit.freebsd.org/ports/tree/www/firefox/files/patch-third__party_sqlite3_src_moz.build
Created attachment 248472 [details] tentative patch v1 I created a patch, based on suggestions here, to ease review/merging. I think protecting the added flag with a conditional check for FreeBSD is a good idea. Makes the patch upstreamable. WARNING: This is untested! I hope to be able to test this patch tomorrow.
(In reply to Guido Falsi from comment #34) I built 123.0 (rc3) and the problem still exists. Building it again with "tentative patch v1" fixed the problem. $ ldd -a /usr/local/lib/firefox/libgkcodecs.so /usr/local/lib/firefox/libgkcodecs.so: libm.so.5 => /lib/libm.so.5 (0x400070e0000) libthr.so.3 => /lib/libthr.so.3 (0x400056be000) libc.so.7 => /lib/libc.so.7 (0x400059f1000) /lib/libm.so.5: libc.so.7 => /lib/libc.so.7 (0x400059f1000) /lib/libthr.so.3: libc.so.7 => /lib/libc.so.7 (0x400059f1000) [preloaded] [vdso] (0x7ffffffff650)
(In reply to Ale from comment #35) That must be something happening: On my current-4594eb454891 amd64 I have firefox 123.0_1,2 running ok and no libm on ldd: ldd -a /usr/local/lib/firefox/libgkcodecs.so /usr/local/lib/firefox/libgkcodecs.so: libthr.so.3 => /lib/libthr.so.3 (0x187e27cb3000) libc.so.7 => /lib/libc.so.7 (0x187e29d93000) /lib/libthr.so.3: libc.so.7 => /lib/libc.so.7 (0x187e29d93000) [preloaded] [vdso] (0x187e2759e000) Could this be related to libsys changes in current?
(In reply to Nuno Teixeira from comment #36) I have no real explanation for that. Maybe it depends on options in some other (multimedia presumably) port, although that should show up in ldd output. What options have you compiled firefox with? Output of `pkg info firefox` should be enough. Maybe we can get some hint there...
(In reply to Guido Falsi from comment #34) Thanks! Built and running fine with your patch. stable/14, amd64. Note that as I haven't built firefox without any of fixes, not sure firefox without fix starts OK or not on my environment. I currently don't have enough time purely for testing, and I use firefox as my main browser.
(In reply to Nuno Teixeira from comment #36) Not likely. As libsys is , IIUC, basically syscall portion of libc splitted out and treated as filtee, keeping filter in libc and at least libthr.
(In reply to Guido Falsi from comment #37) Default options on all ports included firefox.
(In reply to Guido Falsi from comment #34) I've fixed my problem without patch, by adding .if ${.CURDIR:M*/www/firefox} LDFLAGS+= -lm .endif to make.conf (ports.conf) $ ldd -a /usr/local/lib/firefox/libgkcodecs.so /usr/local/lib/firefox/libgkcodecs.so: libm.so.5 => /lib/libm.so.5 (0x355ab3b33000) libthr.so.3 => /lib/libthr.so.3 (0x355ab560f000) libc.so.7 => /lib/libc.so.7 (0x355ab4421000) /lib/libm.so.5: libc.so.7 => /lib/libc.so.7 (0x355ab4421000) /lib/libthr.so.3: libc.so.7 => /lib/libc.so.7 (0x355ab4421000) [preloaded] [vdso] (0x355ab24d0000) <...> Options : ALSA : off CANBERRA : off DBUS : off DEBUG : off FFMPEG : on JACK : off LIBPROXY : off LTO : off OPTIMIZED_CFLAGS: on PROFILE : on PULSEAUDIO : off SNDIO : off TEST : off <...>
(In reply to jakub_lach from comment #41) Ok, but, this is the same as adding LDFLAGS to the port Makefile. What needs to be ascertained before an action can be taken in the ports tree is why some people are affected and others not. I suspect it can be an order of installation/update of the packages. Maybe unaffected people just have still not happened to reinstall or update some package. Or maybe, if their building their own packages, their poudriere/local bulds, have built things in a different order and sometimes the issue is not triggered. This can happen due to updating the ports tree at different time, triggering different logic in the build tools. But this is just a theory and a very difficult one to verify. The problem is, is this a temporary issue due to affected people having been unlucky, and it will simply solve itself at some point? Or is this something that will be affecting everyone at some point? Also, official packages built by the cluster are affected?
(In reply to Guido Falsi from comment #42) Another possibility is that "what GPU (driver) is used" is affecting. And using X or Wayland (possibly with xwayland). These could affect indirectly and does not appear in difference of dependenc chain. For example, IIUC, Gtk3, which is depended upon by firefox, supports both X and Wayland. So which are actually used can affect, theoretically. Is it "practically" possible?
(In reply to Nuno Teixeira from comment #36) I have the same output for ldd and a running firefox on amd64 stable/13 (13.3-STABLE) building it without CPUTYPE in make.conf.
(In reply to Vladimir Druzenko from comment #18) Overall from this PR I have strong suspicion that only some cputypes optimizations might use (need) libm, compare - https://github.com/llvm/llvm-project/issues/33427 If this is true, other ports might fail too.
OK. I already have working (patched) pkg of firefox. So backing up the pkg, backed out the patch and rebuilt firefox. The rebuilt one didn't start, while restoring patched one fixed the issue. Broken one shows % ldd -a /usr/local/lib/firefox/libgkcodecs.so /usr/local/lib/firefox/libgkcodecs.so: libthr.so.3 => /lib/libthr.so.3 (0x75e32c8d000) libc.so.7 => /lib/libc.so.7 (0x75e32081000) /lib/libthr.so.3: libc.so.7 => /lib/libc.so.7 (0x75e32081000) [preloaded] [vdso] (0x75e3043d000) While working one shows % ldd -a /usr/local/lib/firefox/libgkcodecs.so /usr/local/lib/firefox/libgkcodecs.so: libm.so.5 => /lib/libm.so.5 (0x1b73ecfe1000) libthr.so.3 => /lib/libthr.so.3 (0x1b73ec529000) libc.so.7 => /lib/libc.so.7 (0x1b73eda01000) /lib/libm.so.5: libc.so.7 => /lib/libc.so.7 (0x1b73eda01000) /lib/libthr.so.3: libc.so.7 => /lib/libc.so.7 (0x1b73eda01000) [preloaded] [vdso] (0x1b73eaeb7000) And as already posted, I have .if !${.CURDIR:M/usr/src/sys/boot*} CPUTYPE?= haswell .endif in my /etc/Make.conf. So CPUTYPE should be haswell here. Using xorg with x11/nvidia-driver (`startx` from vty). No DRM kmods. Options are as follows. # This file is auto-generated by 'make config'. # Options for firefox-117.0_2,2 _OPTIONS_READ=firefox-117.0_2,2 _FILE_COMPLETE_OPTIONS_LIST=CANBERRA DBUS DEBUG FFMPEG LIBPROXY LTO OPTIMIZED_CFLAGS PROFILE TEST ALSA JACK PULSEAUDIO SNDIO OPTIONS_FILE_UNSET+=CANBERRA OPTIONS_FILE_SET+=DBUS OPTIONS_FILE_UNSET+=DEBUG OPTIONS_FILE_SET+=FFMPEG OPTIONS_FILE_UNSET+=LIBPROXY OPTIONS_FILE_UNSET+=LTO OPTIONS_FILE_SET+=OPTIMIZED_CFLAGS OPTIONS_FILE_SET+=PROFILE OPTIONS_FILE_UNSET+=TEST OPTIONS_FILE_UNSET+=ALSA OPTIONS_FILE_UNSET+=JACK OPTIONS_FILE_SET+=PULSEAUDIO OPTIONS_FILE_UNSET+=SNDIO
(In reply to Tomoaki AOKI from comment #46) If you have .if !${.CURDIR:M/usr/src/sys/boot*} CPUTYPE?= haswell .endif that does not mean it necessarily uses haswell for firefox (see CURDIR above).
(In reply to jakub_lach from comment #47) Yes, if CPUTYPE is defined with CPUTYPE= somewhere else in the build chain. But IIUC, there's none for building firefox. Note that this conditional is for excluding /usr/src/sys/boot* from setting CPUTYPE. This was a remnant, as in ancient days before sources for boot codes moved from /usr/src/sys/boot to /usr/src/stand, setting CPUTYPE for boot codes caused broken boot codes. Currently it's just equivalent as simple "CPUTYPE?= haswell". See "!" (== not) in conditional.
(In reply to jakub_lach from comment #45) Interesting find, although that's an old issue actually. I'd hope it had been solved for good by now. Anyway this makes it possible this depends on CPUTYPE, I actually use "ivybridge" at present (good for the oldest system I build packagers for [1]) Good news is that, official packages should not be affected, due to using no CPUTYPE. Problem is for anyone building packages themselves. Maybe disabling CPUTYPE in the firefox port in some way? (not sure hot to do that, though) [1] Actually I have a mix of intel and AMD machines, so I'm not even sure what common CPUTYPE i should choose for best results
(In reply to Guido Falsi from comment #49) > Maybe disabling CPUTYPE in the firefox port in some way? (not sure hot to do that, though) No, plz, it work fine for me with CPUTYPE?=core2.
(In reply to Vladimir Druzenko from comment #50) I'm not planning on doing it, I was just "brianstorming". This is not an easy thing to fix.
I made a test and compiled firefox without any CPUTYPE set. no -mcpu or -march flags passed to the compiler (according to build logs). And it now works fine, without linking to libm. So at this point I'd say that firefox and the firefox ports are fine, this is a compiler issue. Who should this be pointed out to? P.S. I confess I was skeptical about this but empirical proof wins.
(In reply to Vladimir Druzenko from comment #18) That's actually interesting, as only difference between core2 and penryn (not working here) should be +sse4.1. I assume cputypes after penryn would include it also. (In reply to Guido Falsi from comment #49) Should be solved, but it turned my attention to possible cputypes implications. (In reply to Tomoaki AOKI from comment #48) Right, thanks for clarification.
(In reply to Guido Falsi from comment #52) I was telling that since comment #11! After a running build with all entries commented in make.conf (I was suspecting CFLAGS, or maybe CCACHE) resulting in a running firefox, I did a lot of builds trying to isolate the offending entry. Then, since rc2 and rc3 I always tried the following builds: 1) "full" make.conf => NOT working 2) make.conf with just CPUTYPE (skylake in my case) commented => working (but without libm in ldd output!) always the same reproducible result. And finally, with your patch applied to rc3 + "full" make.conf => OK.
(In reply to Ale from comment #54) and 3) only some CPUTYPEs are affected (see comment #53)
If toolchains used is affecting, new questions arises. *What version affecting with this? As firefox wants wasi-* components for WebAssembly and wasi-* must be in sync with llvm used, base llvm/clang[++] are not used. By defautl, devel/llvm15 and corresponding devel/wasi-* componens are used. *The last commit to wasi-* is at Jan.11,2024, commit eabba650cae3a64d87f6a8345a8819f308326c0e. for devel/llvm15, at Jan.21,2024, commit 1bf7d5ccf65019f3d48cd77ba0f929f0d45f5116, but it was MANPREFIX related. last actual change was at Jan.8,2024, commit 0b672496d6927004bfcb41db685a66750420ead4 to fix build by llvm18. *In contrast with llvm* update history, the last firefox I've not bitten with this problem was 122.0.1_3,2, dated Feb.05,2024. Why didn't we (at least me) be bitten here?
Forgot to mention. Currently, not sure why, cgit.freebsd.org is not responsive. I've searched the commit logs using local `git log HEAD` (PAGER is lv). So no cgit links are listed, although I usually list the URI on cgit for these kind of cases. Sorry. Use any of other repos linked from FreshPorts for now to confirm.
Hey fellas, I have an observation. Had the same error as OP, namely: XPCOMGlueLoad error for file /usr/local/lib/firefox/libgkcodecs.so: /usr/local/lib/firefox/libgkcodecs.so: Undefined symbol "sin" Couldn't load XPCOM. In a few testing scenarios, I tried all the different fix combinations (this box is tracking 13.3-STABLE) as you guys have reported here, without desired result. The build proceeds successfully, but executing firefox fails. For clarity, I've left all files in www/firefox/files/ untouched, deleting/reverting all patches I made myself each time -- in an effort to remain in sync with everything officially made available in the official FreeBSD repo. Just moments ago, I built the port again after the usual git pull for updates, which resulted again in the same error related to libgkcodecs.so we've been having. Then, just on a hunch of "well, whatever, let's give this a shot for a laugh...", I deleted the entire local /usr/ports tree & git cloned a fresh new copy of the entire ports tree. Built the port again, and voila, successfully built & launched FireFox. Using it right now. I have NO clue how/why this has happened. My /etc/make.conf file has remained untouched throughout. In fact, it has remained untouched for over a year now. All I've got in my make.conf file: CPUTYPE?=skylake-avx512 Yes, the CPU is indeed a model listed that can take advantage of this CPUTYPE option; which has so far never caused a problem. This fact would seem to undermine, at least partially perhaps, the suspicion cputypes has something to do with the bug -- as the bug presented with my previous local (stale?) ports tree, versus the bug being resolved *after* git cloning a fresh new ports tree. Might this be a case that the issue is actually elsewhere in the ports tree? However when I rebuilt, no other new/old ports were pulled into the fold, the sole port being built & installed was www/firefox... a conundrum, indeed.
(In reply to fgorter from comment #58) Have you checked if the (problematic) built have pulled in libm and/or tried preloading library as above? I don't think that ports tree can get 'stale' if it is tracked inline with git repo. More probable would be that some optimizations might result in nondeterministic output, actually working without libm in your case.
I don't know what the code inside is, but it seems to me that /usr/local/lib/firefox/dependentlibs.list has something to do with the order in which shared libraries are loaded. If Firefox does not start because libm is missing, move libmozgtk.so above libgkcodecs.so and it will start. I am affected by this issue on 12.4-STABLE, so I won't participate too actively here :)
(In reply to Tatsuki Makino from comment #60) It seems that /usr/local/lib/firefox/dependentlibs.list is genelated by ${WRKSRC}/toolkit/library/build/dependentlibs.py. According to the py script, the format of the list is that the last line is the library that was used to generate the file, and the line before that seems to be the library that the library needs. Therefore, the difference in the results of readelf -d /usr/local/lib/firefox/libxul.so will be one of the bifurcations that causes this problem...
(In reply to Tatsuki Makino from comment #61) Interesting. Maybe dependentlibs.list is read at start to open dependent library files. As you said in comment #60 moving libmozgtk.so before libgkcodecs.so works, maybe because libmozgtk.so is linked with libgtk-3.so.0 which is linked with libm.so.5, so libm.so.5 gets loaded and so sin is available to libgkcodecs.so. But, assuming that the order in dependentlibs.list is the same whether CPUTYPE is specified or not in make.conf, I don't understand why is working for me in the latter case. Maybe I should try another build a check that file...
(In reply to Ale from comment #62) A change here could be used as one of the workarounds, but it is not a fundamental solution. Because the presence or absence of -march changes whether /usr/local/lib/firefox/firefox is linked to libm or not. For example, write code that uses sin. The -O optimization hardcodes the computed result :) so... int main(int argc, char * argv[]) { double d; d = sin(atof(argv[1])); printf("%f\n", d); return 0; } When this is linked by clang, the -lm specification is mandatory. When this is linked by clang++, libm is automatically linked. Let's look at the results of the following command. clang++15 -E -x c -std=gnu17 -dM /dev/null clang++15 -E -x c -std=gnu17 -march=haswell -dM /dev/null These make a difference. The answer is the following. +#define __AVX2__ 1 +#define __AVX__ 1 +#define __BMI2__ 1 +#define __BMI__ 1 +#define __CRC32__ 1 +#define __F16C__ 1 +#define __FMA__ 1 +#define __FSGSBASE__ 1 +#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 1 +#define __INVPCID__ 1 +#define __LAHF_SAHF__ 1 +#define __LZCNT__ 1 +#define __MOVBE__ 1 +#define __PCLMUL__ 1 +#define __POPCNT__ 1 +#define __RDRND__ 1 +#define __SSE3__ 1 +#define __SSE4_1__ 1 +#define __SSE4_2__ 1 +#define __SSSE3__ 1 +#define __XSAVEOPT__ 1 +#define __XSAVE__ 1 -#define __k8 1 -#define __k8__ 1 +#define __corei7 1 +#define __corei7__ 1 -#define __tune_k8__ 1 +#define __tune_corei7__ 1 The code that switches something by this is around firefox-123.0/mozglue/misc/SSE.h 。 This may have prevented haswell from using functions that would have required libm. This may be why they don't link libm with firefox binary. In other words, a change to link libm to some binary that cannot avoid using libm sin would be a good solution. So much for what I have researched :)
(In reply to Tatsuki Makino from comment #63) Can simd(7) affect? https://man.freebsd.org/cgi/man.cgi?query=simd&apropos=0&sektion=0&manpath=FreeBSD+15.0-CURRENT&arch=default&format=html
(In reply to Tomoaki AOKI from comment #64) Hmmm, I don't know :) It seems to me that if we replace the y=x/60;z=x%60; calculation with div, Intel's CPU reduces the division from twice to once. Back to firefox, Sorting and comparing the poudriere logs, the following differences occur in certain areas. @@ -64970,17 +64944,12 @@ ld.lld: warning: undefined symbol: aom_codec_version_str ld.lld: warning: undefined symbol: aom_img_wrap ld.lld: warning: undefined symbol: atan -ld.lld: warning: undefined symbol: ceil ld.lld: warning: undefined symbol: cos ld.lld: warning: undefined symbol: exp ld.lld: warning: undefined symbol: exp2 -ld.lld: warning: undefined symbol: floor -ld.lld: warning: undefined symbol: floorf ld.lld: warning: undefined symbol: log ld.lld: warning: undefined symbol: log10 ld.lld: warning: undefined symbol: pow -ld.lld: warning: undefined symbol: rint -ld.lld: warning: undefined symbol: rintf ld.lld: warning: undefined symbol: sin leads to different rendering results, and you might change port's options to line to the "Modules" section of your X Windows configuration file: It means that the use or non-use of -march=haswell will change whether these functions are used or not. Other parts that do not change should certainly be linked to libm, but what should the link be for the parts that have functions that change?
(In reply to Tatsuki Makino from comment #65) According to math(3) manpage, lines including and below atan seems to be belong to libm. So libm shoule be required regardless dropped lines for blank CPUTYPE exist or not. (Need to resolve left unresolved symbols.) Possobly, it could be a race condition, promissingly settled at build time. For old CPUTYPE, libm is required by any of libraries other than the problematic one, thus symbols can be resolved, but for newer CPUTYPE, added instruction sets cause the problematic one to be loaded before any other library require libm. Does it look reasonable? Codecs would usually require libm like 2 examples below. % ldd -a /usr/local/lib/libvpx.so.9.0.0 /usr/local/lib/libvpx.so.9.0.0: libthr.so.3 => /lib/libthr.so.3 (0x2135faafd000) libm.so.5 => /lib/libm.so.5 (0x2135fabb9000) libc++.so.1 => /lib/libc++.so.1 (0x2135fb0e5000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x2135fb299000) libc.so.7 => /lib/libc.so.7 (0x2135fbbf6000) /lib/libthr.so.3: libc.so.7 => /lib/libc.so.7 (0x2135fbbf6000) /lib/libm.so.5: libc.so.7 => /lib/libc.so.7 (0x2135fbbf6000) /lib/libc++.so.1: libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x2135fb299000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2135fd6d1000) libc.so.7 => /lib/libc.so.7 (0x2135fbbf6000) /lib/libcxxrt.so.1: libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2135fd6d1000) libc.so.7 => /lib/libc.so.7 (0x2135fbbf6000) /lib/libgcc_s.so.1: libc.so.7 => /lib/libc.so.7 (0x2135fbbf6000) [preloaded] [vdso] (0x2135f8f3e000) % ldd -a /usr/local/lib/libopus.so.0.9.0 /usr/local/lib/libopus.so.0.9.0: libm.so.5 => /lib/libm.so.5 (0x1f58e8f10000) libc.so.7 => /lib/libc.so.7 (0x1f58e9727000) /lib/libm.so.5: libc.so.7 => /lib/libc.so.7 (0x1f58e9727000) [preloaded] [vdso] (0x1f58e87ae000)
Status: aarch64 (rpi4) - main and poudriere jail @ 3733d82c4deb - build from a cleaned pkgs poudriere - `pkg delete -af` && install pkgs `firefox`: same error as mentioned. Rebuilding only firefox now with PR patch. Tomorrow I will share results.
(In reply to Tomoaki AOKI from comment #66) Perhaps so. Looking a little more closely, first, the commands to which /usr/local/lib/firefox/firefox is linked are as follows. All seemingly unimportant parts were replaced with "...". /usr/local/bin/clang++15 -std=gnu++17 -o ../../dist/bin/firefox ... -O2 -pipe -march=haswell -O3 ... -funwind-tables /wrkdirs/usr/ports/www/firefox/work/.build/browser/app/firefox.list -pthread -Wl,--as-needed ... -fuse-ld=lld ... -rdynamic ... ../../build/pure_virtual/libpure_virtual.a -pie -L/usr/local/lib There is no such thing as a -lm being added by CPUTYPE. The link to libm relies completely on the behavior of clang++. The resulting firefox binary will show the following differences in readelf -s. Filtered and sorted by cut -w -f 9. @@ -664,22 +664,10 @@ _ZN7mozilla11Compression3LZ48compressEPKcmPc _ZN7mozilla11sse_private11aes_enabledE _ZN7mozilla11sse_private11aes_enabledE -_ZN7mozilla11sse_private11avx_enabledE -_ZN7mozilla11sse_private11avx_enabledE -_ZN7mozilla11sse_private12avx2_enabledE -_ZN7mozilla11sse_private12avx2_enabledE _ZN7mozilla11sse_private12fma3_enabledE _ZN7mozilla11sse_private12fma3_enabledE -_ZN7mozilla11sse_private12sse3_enabledE -_ZN7mozilla11sse_private12sse3_enabledE _ZN7mozilla11sse_private13sse4a_enabledE _ZN7mozilla11sse_private13sse4a_enabledE -_ZN7mozilla11sse_private13ssse3_enabledE -_ZN7mozilla11sse_private13ssse3_enabledE -_ZN7mozilla11sse_private14sse4_1_enabledE -_ZN7mozilla11sse_private14sse4_1_enabledE -_ZN7mozilla11sse_private14sse4_2_enabledE -_ZN7mozilla11sse_private14sse4_2_enabledE _ZN7mozilla11sse_private15avxvnni_enabledE _ZN7mozilla11sse_private15avxvnni_enabledE _ZN7mozilla11sse_private16has_constant_tscE @@ -1915,8 +1903,6 @@ bcmp@FBSD_1.0 calloc calloc@FBSD_1.0 -ceil -ceil@FBSD_1.0 clock_getres clock_getres@FBSD_1.0 clock_gettime @@ -1957,8 +1943,6 @@ fileno fileno@FBSD_1.0 finalizer -floor -floor@FBSD_1.0 fopen fopen@FBSD_1.0 fprint_stderr By leaving ceil and floor to what is in the CPU, it would mean that libm would be unnecessary. When pure_virtual is traced to where it comes from, ${WRCSRC}/build/pure_virtual/pure_virtual.c is reached. But it is almost empty inside and I am not sure. I suspect that ${WRKDIR}/.build/browser/app/firefox.list is involved in the contents of this binary, but I am not sure. Also, libgkcodecs.so link seems to use clang instead of clang++. This would require explicitly linking libm with -lm, as already said. A similar fix would be needed for all *.so that they received the undefined symbol warning. Is that a good rationale for applying the patch? :)
(In reply to Tatsuki Makino from comment #68) I cannot understand why CPUTYPE causes ceil() and floor() is used or not. Just a possibility, for slow and old CPUTYPEs, firefox has alternative, maybe scale and int'ify then calculate as integer, and fp'fy with scaling again. If it's correct, this problem can be happen, but really?! Moreover, such a implementation should require guarded inclusion of math.h using CPUTYPE and/or arch. If none, and if math.h is included regardless directly or indirectly, blindly adding -lm option for the module should be fine. Reading /usr/include/math.h, most of mathematic functions are defined as usual prototype only, including sin(), atan(), ceil() and floor(). As, IIUC, C doesn't have specs to seek for function bodies which are not in #include chain, inline them, and render to instruction which can do it directly. So if there's only prototypes of needed function in the header file included, corresponding library must be linked.
(In reply to Tomoaki AOKI from comment #69) > I cannot understand why CPUTYPE causes ceil() and floor() is used or not. Me too :) There is no reason for this anywhere in the Firefox source code. So a new experiment will be made. #include <math.h>, <stdlib.h> and <stdio.h> int main(int argc, char * argv[]) { double d; d = ceil(floor(atof(argv[1]))); printf("%f\n", d); return 0; } ~ Compile it with the following options clang15 -S -O0 -march= /tmp/test_src.c clang15 -S -O0 -march=haswell /tmp/test_src.c It would make the file with the suffix changed to s. If -march= is empty, there is a callq of ceil and floor. If -march=haswell then it does not exist. vroundsd is used for floor and ceil. This seems to be an SSE4 instruction, so CFLAGS+=-mno-sse4 is the minimal workaround. Could this time be the basis for a correct patch? :)
(In reply to Nuno Teixeira from comment #67) > Status: aarch64 (rpi4) > - main and poudriere jail @ 3733d82c4deb > - build from a cleaned pkgs poudriere > - `pkg delete -af` && install pkgs > `firefox`: same error as mentioned. Patch fixes issue.
(In reply to Tatsuki Makino from comment #70) > This seems to be an SSE4 instruction, so CFLAGS+=-mno-sse4 is the > minimal workaround. How could that affect aarch64 like I'm experience on rpi4?
(In reply to Tatsuki Makino from comment #70) Interesting. But resulting assembly codes seems to be reverse with what happened. For "-march=" case, libm should be surely needed, while "-march=haswell" case, possibly not needed (functions in libm are not called). But what's happening is that sane boot with blank (default) CPUTYPE) but fais without "-lm" on CPUTYPE=haswell case. And assuming the problematic library is a codec as of its name, disabling sse* and/or avx+ options could result in severe performance degradation when they are actually available. Moreover, some of external libraries linked against libxul.so (IIUC, a core component of firefox) are linked against libm. So blindly linking with libm looks reasonable foe me. As libxul.so itself is linked with libm could be because of the patch, list others below. (Picked from outputs of `ldd -a usr/local/lib/firefox/libxul.so`.) usr/local/lib/libicui18n.so.74 /usr/local/lib/libicuuc.so.74 /usr/local/lib/libaom.so.3 /usr/local/lib/libgdk-3.so.0 /usr/local/lib/libharfbuzz.so.0 /usr/local/lib/libpango-1.0.so.0 /usr/local/lib/libgtk-3.so.0 /usr/local/lib/libcairo.so.2 /usr/local/lib/libcairo-gobject.so.2 /usr/local/lib/libpng16.so.16 /usr/local/lib/libwebp.so.7 /usr/local/lib/libvpx.so.9 /usr/local/lib/libpixman-1.so.0 /usr/local/lib/libvmaf.so.3 /usr/local/lib/libbrotlidec.so.1 /usr/local/lib/libexpat.so.1/usr/local/lib/libsharpyuv.so.0 /usr/local/lib/libpangocairo-1.0.so.0 /usr/local/lib/libsharpyuv.so.0 /usr/local/lib/libbrotlicommon.so.1
(In reply to Tatsuki Makino from comment #70) > This seems to be an SSE4 instruction, so CFLAGS+=-mno-sse4 is the minimal workaround. > Could this time be the basis for a correct patch? :) This would be inline with what I've wrote in comment #53 - working (core2) and not working (penryn) CPUTYPE march should differ only by -mno-sse4.1 / -msse4.1
(In reply to jakub_lach from comment #74) > I've wrote in comment #53 Yeah, you got 🥇 I got 🥈 or 🥉 on 𔔪 or nothing 🤣 But this can only be a workaround-patch, and we will need a fix-patch. It seems that amd64 has reached a solution, but there is a reason why it doesn't work on aarch64 as well. (In reply to Tomoaki AOKI from comment #73) Hmmm, this seems to be one cause and a combination of many different parts. Perhaps :) First, the entry point, /usr/local/lib/firefox/firefox binary, is linked without -lm. But it uses clang++15 to do the linking, so if libm is needed, it is automatically linked. Furthermore, since the only reason the binary needs libm is to use the floor and ceil functions, those functions will no longer exist when compiled using -march=havesse4.1cpu or -msse4.1, and libm will not be automatically linked. Then, when firefox starts, it loads additional libraries. The order depends on /usr/local/lib/firefox/dependentlibs.list. However, this order is not altered by the definition of CPUTYPE. It doesn't matter. The first on that list, libgkcodecs.so, is a library that requires libm, but libm is not linked. Therefore, whether or not libm is loaded at this point determines whether the startup is a success or failure. It is in this vein, hmmm. So far this is for amd64, and from here on for aarch64. (In reply to Nuno Teixeira from comment #72) The libraries to be linked may have changed for the same reason in aarch64. However, if the conditions under which it is started do not exist at all, then a patch is needed to suppress all of the following warnings. ld.lld: warning: undefined symbol: floor It is not only about floor. All commands seem to include -Wl,--as-needed when linking, so unnecessary libraries will not be linked. It would not be a problem for libraries that change whether they are used or not to also always be specified. Also, I don't seem to be able to cross-compile aarch64 in the environment I have, so we'll have to get someone else to help with the interesting experiments. That is Mark-san, for example :)
Just to report that the problem still exists in firefox-123.0.1,2.
(In reply to Ale from comment #76) Did you apply patches? Running it right now at 15 (51c6bf0), firefox 123.0_4,2.
(In reply to Nuno Teixeira from comment #77) (...) Sorry, misread: 123.0.1 Same error?
(In reply to Ale from comment #76) BTW, please change importance to "Affects Some People", 17 already CC'd.
(In reply to Nuno Teixeira from comment #77) It is unclear, at this point, if the patch I attached (based on suggestions in previous commits) is the correct solution. It is more like a workaround. Looks like this is caused by variable behaviour of the compiler depending on the CPU it is compiling for. Could be a bug in the compiler or even something more complex. Unluckily I don't have a general solution for this. Using the "workaround" patch attached by me here should have no negative consequences, anyway.
(In reply to Nuno Teixeira from comment #78) Yes, same error. Since 123.0 rc1, for every update on www/firefox I'm trying a "normal" build (normal as normal for me, with CPUTYPE?=...) and then (as it's not working) a build with the workaround patch from Guido.
(In reply to Guido Falsi from comment #80) I think attachment 248472 [details] (comment #30) is not just a workaround, but a necessary upstream fix. The other point that needs to be fixed is that multimedia libraries such as aom are trying to link against libxul.so. It can be found by "-o libxul\.so" being grep'd. Libraries such as aom and dav1d are considered sufficient to be linked towards libmozavcodec.so. It is the libm that is troublesome :) Whenever libgkcodecs.so is linked, it is likely to need to be linked at any time because there is not enough libm. It is an attachment 248472 [details]. Leave the other parts to the C++ linker's ability to link on its own :) This may be related to a built-in function as described in /usr/src/contrib/llvm-project/clang/include/clang/Basic/Builtins.def, but I don't know :) Preference is given to built-in functions, but if they are not available, link to outside libraries. We can presume that it is likely to do so automatically. It seems that it may be another problem (rust?) that is not working with aarch64. Without some resolution to this issue, it will be difficult to get started on that one, maybe...
I'm unlucky man. :-( First, encountered build failure (as in bug #277075). Now, I can confirm I'm also affected by this one: $ firefox XPCOMGlueLoad error for file /usr/local/lib/firefox/libgkcodecs.so: /usr/local/lib/firefox/libgkcodecs.so: Undefined symbol "sin" Couldn't load XPCOM. Rebuilding with libm patch once more...
The problem with aom-related symbols (ld.lld: warning: undefined symbol: aom_*) could be fixed with www/firefox/files/patch-bug1559213 modification. This file seems to be an attempt to use libaom in conjunction with the activation of MOZ_AV1. If so, we would have to add the libaom flags and libraries at the same time in patch for media/ffvpx/libavcodec/moz.build. Like this :) + if CONFIG["MOZ_SYSTEM_AV1"]: + CFLAGS += CONFIG['MOZ_SYSTEM_LIBDAV1D_CFLAGS'] + OS_LIBS += CONFIG['MOZ_SYSTEM_LIBDAV1D_LIBS'] + CFLAGS += CONFIG['MOZ_SYSTEM_LIBAOM_CFLAGS'] + OS_LIBS += CONFIG['MOZ_SYSTEM_LIBAOM_LIBS'] + else: + USE_LIBS += [ + 'dav1d', + 'media_libdav1d_asm', + 'aom', + ] But, this is my fantasy. I have not tested it yet :)
It seems to me that ${WRKSRC}/browser/app/moz.build should be patched to also link libm when linking firefox or firefox-bin binaries. Perhaps the following would be added OS_LIBS += [ "m", ] Naturally, I have not yet tested this as well :) Sometimes -Wl,--as-needed option of the linker is always used as a convenience option, but it is probably the original meaning of this option to be used for libm :)
(In reply to Anton Saietskii from comment #83) So, I can confirm that rebuild with libm patch made firefox run again.
Created attachment 248988 [details] Still incomplete patch for www/firefox So here is a patch of my comment #84 #85 plan :) This has been internalized in attachment 248472 [details] patch. However, it is written in a similar format to the surrounding format, with changes to the conditions under which it can be submitted upstream. This suppresses all warnings of undefined symbols. -o ../../dist/bin/firefox links will always contain -lm. However, it is not linked when it is not needed. It is as intended. Those built in an environment where CPUTYPE=core-avx2 is specified and -march=haswell is used can be started successfully. However, this was only tested on 12.4-STABLE amd64. As you can see from the contents of this patch, the format has become a chimera. Some kind of correction is needed.
(In reply to Ale from comment #11) Same with me too, I'm trying to login my https://ncedcloudam.com/ lms it's keep giving me error "failed internet connection" but it's working perfectly on other browser.
(In reply to Stefan Ehmann from comment #9) Just an FYI, i still have this issue on latest 14 and FF, this is the only thing that makes it work.
(In reply to Tatsuki Makino from comment #87) These patches seem to have fixed the error for me. I have CPUTYPE?=znver3.
Running 15.0-CURRENT #0 main-n268989-caccf6d3c008 The patch worked for me. firefox --version Mozilla Firefox 124.0.1
(In reply to Vlad Biley from comment #90) Seems like a PITA for user to have to do, i use CPUTYPE?=native, evefything works except for FF.
(In reply to mike jakubik from comment #92) Yes, I agree it's a PITA. I believe that in the near future the patch will be added to the official ports tree or even upstream (TBH, I don't understand the essence of the problem very well). Until then, if you don't want to patch Firefox locally, an easier workaround was suggested here in comment #9. Regarding CPUTYPE?=native. I saw advice on the FreeBSD forum that it's better to specify your CPUTYPE explicitly (see /usr/share/examples/etc/make.conf) because "native" doesn't seem to work as expected.
(In reply to Vlad Biley from comment #93) I see, i guess i need znver3 or this then? CPU: AMD Ryzen 9 5950X 16-Core Processor (4100.15-MHz K8-class CPU) Origin="AuthenticAMD" Id=0xa20f10 Family=0x19 Model=0x21 Stepping=0 Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> Features2=0x7ef8320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM> AMD Features2=0x75c237ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT,TCE,Topology,PCXC,PNXC,DBE,PL2I,MWAITX,ADMSKX> Structured Extended Features=0x219c97a9<FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,PQE,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA> Structured Extended Features2=0x40069c<UMIP,PKU,OSPKE,VAES,VPCLMULQDQ,RDPID> Structured Extended Features3=0x10<FSRM> XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES> AMD Extended Feature Extensions ID EBX=0x111ef657<CLZERO,IRPerf,XSaveErPtr,RDPRU,WBNOINVD,IBPB,IBRS,STIBP,STIBP_ALWAYSON,PREFER_IBRS,SSBD> SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics
(In reply to mike.jakubik from comment #94) Yep, it's Zen 3 so znver3.
The same bug for me with 124.0.1_1,2 with CPUTYPE?=bdver2 on 14-STABLE. Still it is. (
vvd@, please also change importance to "Affects Many People". I believe it's time.
The latest version now throws this error with the LD_PRELOAD=/lib/libm.so.5 /usr/local/lib/firefox/libxul.so: Undefined symbol "_ZN25nsUnixSystemProxySettings20GetSystemWPADSettingEPb"
(In reply to Jack from comment #98) This is unrelated. It is triggered by turning on the PROXY option (which is off by default): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 https://lists.freebsd.org/archives/dev-commits-ports-all/2024-April/109511.html
(In reply to Guido Falsi from comment #99) To further elaborate, this is an upstream regression in the latest version, as far as I understand.
Rebuild with LIBPROXY off fixed the issue with "_ZN25nsUnixSystemProxySettings20GetSystemWPADSettingEPb".
(In reply to Vlad Biley from comment #95) That fixed it for me.
(In reply to jakub_lach from comment #41) I was seeing the same problem with www/librewolf on -current arm64.aarch64 so put this in the make.conf for poudriere: .if ${.CURDIR:M*/www/firefox} LDFLAGS+= -lm .endif # .if ${.CURDIR:M*/www/librewolf} LDFLAGS+= -lm .endif and rebuilt, reinstalled, and the problem "XPCOMGlueLoad error for file /usr/local/lib/librewolf/libgkcodecs.so: /usr/local/lib/librewolf/libgkcodecs.so: Undefined symbol "sin" Couldn't load XPCOM." has gone
*** Bug 278638 has been marked as a duplicate of this bug. ***