Date: Wed, 14 Sep 2022 20:49:52 -0700 From: Mark Millard <marklmi@yahoo.com> To: void <void@f-m.fm>, freebsd-arm <freebsd-arm@freebsd.org> Subject: RE: gcc failure on -current on aarch64 Message-ID: <C7808F77-FF87-42FE-8E0C-50228D140E7A@yahoo.com> References: <C7808F77-FF87-42FE-8E0C-50228D140E7A.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
void <void_at_f-m.fm> wrote on
Date: Wed, 14 Sep 2022 16:20:18 UTC :
> I'm not sure whether to raise a ports PR for this, or if it's
> an aarch64 problem or if it's a -current problem so if this is the
> wrong list, please advise.
>=20
> On a php80 installlation running recent -current using ports
> built yesterday in poudriere with a fresh ports tree, php80-gd
> upgraded but now php complains like this:
>=20
> PHP Startup: Unable to load dynamic library 'gd.so' \
> (tried: /usr/local/lib/php/20200930/gd.so (/lib/libgcc_s.so.1: \
> version GCC_4.5.0 required by /usr/local/lib/gcc11/libstdc++.so.6 not =
found), \
> /usr/local/lib/php/20200930/gd.so.so (/lib/libgcc_s.so.1: version =
GCC_4.5.0 \
> required by /usr/local/lib/gcc11/libstdc++.so.6 not found)) in Unknown =
\
> on line 0
>=20
> Sure enough, GCC_4.5.0 isn't there
>=20
> # strings /lib/libgcc_s.so.1 | ug GCC_
>=20
> 180: GCC_3.0
> 181: GCC_3.3
> 182: GCC_3.3.1
> 183: GCC_3.4
> 184: GCC_3.4.2
> 185: GCC_3.4.4
> 186: GCC_3.5
> 187: GCC_4.0.0
> 188: GCC_4.2.0
> 189: GCC_4.3.0
> 190: GCC_4.6.0
>=20
> # strings /usr/local/lib/gcc11/libstdc++.so.6 | ug GCC_
>=20
> 6111: GCC_4.2.0
> 6112: GCC_3.3
> 6113: GCC_3.0
> 6114: GCC_4.5.0
>=20
> Is the problem with base/ports/gcc{version}, gd, php?
>=20
> freebsd-current is main-n257818 built 5th Sept
[I've run into this issue in multiple contexts recently.
But I figured I'd leave notes here on the list as well.]
For aarch64 specifically, FreeBSD's /lib/libgcc_s.so.1 simply
does not provide everything that the various
/usr/local/lib/gcc*/libstdc++.so.6
require, including for g++11 use. (Even plain C code can run
into the general issue --but usually does not happen to use
something that does. libstdc++.so.6 from older lang/gcc* and
g++ code generation also run into the issue.)
Because of this /lib/libgcc_s.so.1 mismatch for aarch64,
/usr/local/lib/gcc11/libstdc++.so.6 needs to find:
/usr/local/lib/gcc11/libgcc_s.so.1
instead of
/lib/libgcc_s.so.1
That, in turn, means that if g++11 (for example) is used as
a front end command for linking,
-Wl,-rpath=3D/usr/local/lib/gcc11
should be involved in the command as well.
An example of without and with ( lang/gcc12 context ):
# g++12 trivial.cpp
# ldd ./a.out
./a.out:
libstdc++.so.6 =3D> /usr/local/lib/gcc12/libstdc++.so.6 =
(0x400000)
libm.so.5 =3D> /lib/libm.so.5 (0x400000)
libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x400000)
libc.so.7 =3D> /lib/libc.so.7 (0x400000)
# ./a.out
ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by =
/usr/local/lib/gcc12/libstdc++.so.6 not found
vs.:
# g++12 -Wl,-rpath=3D/usr/local/lib/gcc12 trivial.cpp
# ldd ./a.out
./a.out:
libstdc++.so.6 =3D> /usr/local/lib/gcc12/libstdc++.so.6 =
(0x400000)
libm.so.5 =3D> /lib/libm.so.5 (0x400000)
libgcc_s.so.1 =3D> /usr/local/lib/gcc12/libgcc_s.so.1 (0x400000)
libc.so.7 =3D> /lib/libc.so.7 (0x400000)
# ./a.out
#
This means that the ports using libstdc++.so.6 need to deal
with getting the builds to have the required rpath(s) in place
for the g++* involved. (gcc* generated code can also end up
requiring such.)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C7808F77-FF87-42FE-8E0C-50228D140E7A>