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