Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 Feb 2024 00:41:42 +0000
From:      bugzilla-noreply@freebsd.org
To:        gecko@FreeBSD.org
Subject:   [Bug 277021] www/firefox: error on start after updating to 123.0 (rc1, rc2)
Message-ID:  <bug-277021-21738-0Gej3Ap5MY@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-277021-21738@https.bugs.freebsd.org/bugzilla/>
References:  <bug-277021-21738@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277021

--- Comment #68 from Tatsuki Makino <tatsuki_makino@hotmail.com> ---
(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=3Dgnu++17 -o ../../dist/bin/firefox ... -O2 -=
pipe
-march=3Dhaswell -O3 ... -funwind-tables
/wrkdirs/usr/ports/www/firefox/work/.build/browser/app/firefox.list -pthread
-Wl,--as-needed ... -fuse-ld=3Dlld ... -rdynamic ...=20
../../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 wo=
uld
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? :)

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-277021-21738-0Gej3Ap5MY>