RE: gcc failure on -current on aarch64

From: Mark Millard <marklmi_at_yahoo.com>
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