[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 gja...@narod.ru changed: What|Removed |Added CC||gja...@narod.ru --- Comment #96 from gja...@narod.ru --- The same bug for me with 124.0.1_1,2 with CPUTYPE?=bdver2 on 14-STABLE. Still it is. ( -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #95 from Vlad Biley --- (In reply to mike.jakubik from comment #94) Yep, it's Zen 3 so znver3. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 mike.jaku...@intertainservices.com changed: What|Removed |Added CC||mike.jakubik@intertainservi ||ces.com --- Comment #94 from mike.jaku...@intertainservices.com --- (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 Features2=0x7ef8320b AMD Features=0x2e500800 AMD Features2=0x75c237ff Structured Extended Features=0x219c97a9 Structured Extended Features2=0x40069c Structured Extended Features3=0x10 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x111ef657 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #93 from Vlad Biley --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #92 from mike jakubik --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 Tim Kellers changed: What|Removed |Added CC||trkell...@gmail.com --- Comment #91 from Tim Kellers --- Running 15.0-CURRENT #0 main-n268989-caccf6d3c008 The patch worked for me. firefox --version Mozilla Firefox 124.0.1 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #90 from Vlad Biley --- (In reply to Tatsuki Makino from comment #87) These patches seem to have fixed the error for me. I have CPUTYPE?=znver3. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 mike jakubik changed: What|Removed |Added CC||mike.jaku...@gmail.com --- Comment #89 from mike jakubik --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 Stephanie changed: What|Removed |Added CC||jasminemerc...@outlook.com --- Comment #88 from Stephanie --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #87 from Tatsuki Makino --- Created attachment 248988 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248988=edit Still incomplete patch for www/firefox So here is a patch of my comment #84 #85 plan :) This has been internalized in attachment 248472 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #86 from Anton Saietskii --- (In reply to Anton Saietskii from comment #83) So, I can confirm that rebuild with libm patch made firefox run again. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #85 from Tatsuki Makino ---
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 :)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #84 from Tatsuki Makino --- 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 :) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #83 from Anton Saietskii --- 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... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #82 from Tatsuki Makino --- (In reply to Guido Falsi from comment #80) I think attachment 248472 (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. 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... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #81 from Ale --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 Guido Falsi changed: What|Removed |Added Severity|Affects Only Me |Affects Some People -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #80 from Guido Falsi --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #79 from Anton Saietskii --- (In reply to Ale from comment #76) BTW, please change importance to "Affects Some People", 17 already CC'd. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #78 from Nuno Teixeira --- (In reply to Nuno Teixeira from comment #77) (...) Sorry, misread: 123.0.1 Same error? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #77 from Nuno Teixeira --- (In reply to Ale from comment #76) Did you apply patches? Running it right now at 15 (51c6bf0), firefox 123.0_4,2. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #76 from Ale --- Just to report that the problem still exists in firefox-123.0.1,2. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #75 from Tatsuki Makino --- (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 :) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #74 from jakub_l...@mailplus.pl --- (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 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #73 from Tomoaki AOKI --- (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 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #72 from Nuno Teixeira --- (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? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #71 from Nuno Teixeira --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #70 from Tatsuki Makino ---
(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 , and
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? :)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #69 from Tomoaki AOKI --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #68 from Tatsuki Makino ---
(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? :)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #67 from Nuno Teixeira --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #66 from Tomoaki AOKI --- (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 (0x1f58e8f1) libc.so.7 => /lib/libc.so.7 (0x1f58e9727000) /lib/libm.so.5: libc.so.7 => /lib/libc.so.7 (0x1f58e9727000) [preloaded] [vdso] (0x1f58e87ae000) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #65 from Tatsuki Makino --- (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? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #64 from Tomoaki AOKI --- (In reply to Tatsuki Makino from comment #63) Can simd(7) affect? https://man.freebsd.org/cgi/man.cgi?query=simd=0=0=FreeBSD+15.0-CURRENT=default=html -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #63 from Tatsuki Makino ---
(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 :)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #62 from Ale --- (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... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #61 from Tatsuki Makino ---
(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...
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 Tatsuki Makino changed: What|Removed |Added CC||tatsuki_mak...@hotmail.com --- Comment #60 from Tatsuki Makino --- 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 :) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #59 from jakub_l...@mailplus.pl --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 fgorter changed: What|Removed |Added CC||fgor...@gmail.com --- Comment #58 from fgorter --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #57 from Tomoaki AOKI --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #56 from Tomoaki AOKI --- 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? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #55 from jakub_l...@mailplus.pl --- (In reply to Ale from comment #54) and 3) only some CPUTYPEs are affected (see comment #53) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #54 from Ale --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 Vladimir Druzenko changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2770 ||75 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #53 from jakub_l...@mailplus.pl --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #52 from Guido Falsi --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #51 from Guido Falsi --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #50 from Vladimir Druzenko --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #49 from Guido Falsi --- (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 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #48 from Tomoaki AOKI --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #47 from jakub_l...@mailplus.pl ---
(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).
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #46 from Tomoaki AOKI ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #45 from jakub_l...@mailplus.pl --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #44 from Ale --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #43 from Tomoaki AOKI --- (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? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #42 from Guido Falsi --- (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? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #41 from jakub_l...@mailplus.pl ---
(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] (0x355ab24d)
<...>
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
<...>
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #40 from Nuno Teixeira --- (In reply to Guido Falsi from comment #37) Default options on all ports included firefox. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #39 from Tomoaki AOKI --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #38 from Tomoaki AOKI --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #37 from Guido Falsi --- (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... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #36 from Nuno Teixeira --- (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? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #35 from Ale --- (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 (0x400070e) 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] (0x7650) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #34 from Guido Falsi --- Created attachment 248472 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248472=edit 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #33 from Tomoaki AOKI --- 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 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #32 from Stefan Ehmann --- (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 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #31 from Guido Falsi --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 Jesper Schmitz Mouridsen changed: What|Removed |Added CC||j...@freebsd.org --- Comment #30 from Jesper Schmitz Mouridsen --- --- 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 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #29 from Guido Falsi --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #28 from Guido Falsi --- Having a look at firefox sources I found something interesting in `third_party/libwebrtc/moz-patch-stack/0106.patch`: -- From: Chun-Min Chang Date: Tue, 5 Dec 2023 20:08:00 + 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #27 from Guido Falsi --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #26 from jakub_l...@mailplus.pl --- (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) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #25 from Nuno Teixeira --- (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) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #24 from Guido Falsi --- (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) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021
--- Comment #23 from Ale ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #22 from Tomoaki AOKI --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #21 from Lars Henrik Ørn --- (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 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #20 from Tomoaki AOKI --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 --- Comment #19 from Guido Falsi --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277021 Vladimir Druzenko changed: What|Removed |Added Summary|www/firefox: error on start |www/firefox: error on start |after updating to 123.0 |after updating to 123.0 |(rc1) |(rc1, rc2) -- You are receiving this mail because: You are the assignee for the bug.
