RE: gcc failure on -current on aarch64
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 15 Sep 2022 03:49:52 UTC
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.
>
> 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:
>
> 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
>
> Sure enough, GCC_4.5.0 isn't there
>
> # strings /lib/libgcc_s.so.1 | ug GCC_
>
> 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
>
> # strings /usr/local/lib/gcc11/libstdc++.so.6 | ug GCC_
>
> 6111: GCC_4.2.0
> 6112: GCC_3.3
> 6113: GCC_3.0
> 6114: GCC_4.5.0
>
> Is the problem with base/ports/gcc{version}, gd, php?
>
> 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=/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 => /usr/local/lib/gcc12/libstdc++.so.6 (0x400000)
libm.so.5 => /lib/libm.so.5 (0x400000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x400000)
libc.so.7 => /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=/usr/local/lib/gcc12 trivial.cpp
# ldd ./a.out
./a.out:
libstdc++.so.6 => /usr/local/lib/gcc12/libstdc++.so.6 (0x400000)
libm.so.5 => /lib/libm.so.5 (0x400000)
libgcc_s.so.1 => /usr/local/lib/gcc12/libgcc_s.so.1 (0x400000)
libc.so.7 => /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.)
===
Mark Millard
marklmi at yahoo.com