| View previous topic :: View next topic |
| Author |
Message |
saperski
n00b
Joined: 15 Feb 2022
Posts: 9
|
 Posted: Tue Feb 15, 2022 11:40 pm Post subject: Should gcc 11.2.0 be able to link libstdc++ automatically? |
 |
|
Long story short, I have this few years old(!) Gentoo server waiting to be updated to 2022. After almost two weeks of fight, I am finally able to "emerge -ev @world" based on https://github.com/gentoo/gentoo/tree/03ce0a0988485abe3dad3c455c0146217dc6cfa1
The machine is running profile 17.0 with x86_64-pc-linux-gnu-11.2.0 gcc with x86_64-pc-linux-gnu-2.37_p1 binutils since I wanted to sort things out before attempting 17.1 migration.
In parallel I have deployed a brand new VM with 17.1 with the same compiler/binutils version, following Gentoo Handbook for amd64.
We are using the following MySQL setup (with mysql 8.0 server masked to prevent migration of data):
17.0 box# qlist -Iv |grep mysql
acct-group/mysql-0-r1
acct-user/mysql-0-r1
dev-db/mysql-5.7.36-r1
dev-db/mysql-connector-c-8.0.27
dev-db/mysql-init-scripts-2.3-r3
brand new VM has only this
# qlist -Iv |grep mysql
dev-db/mysql-connector-c-8.0.27
dev-perl/DBD-mysql-4.50.0-r1
The only package that does not emerge on the migrated machine is dev-perl/DBD-mysql:
The command run was: | Code: | | script -c 'emerge --info && emerge -1v dev-perl/DBD-mysql' /tmp/dbd_mysql.log |
| Code: |
Script started on 2022-02-16 00:02:56+01:00 [TERM="screen" TTY="/dev/pts/7" COLUMNS="104" LINES="46"]
]0;emerge
!!! Your current profile is deprecated and not supported anymore.
!!! Use eselect profile to update your profile.
!!! Please upgrade to the following profile if possible:
default/linux/amd64/17.1
To upgrade do the following steps:
The amd64 17.1 profiles switch to a more standard 'no SYMLINK_LIB'
multilib layout, and require an explicit migration. The migration is
performed using the app-portage/unsymlink-lib tool.
Read the Gentoo news item [2] for more information!
The following steps can be used to upgrade your system:
1. Sync and upgrade your system to the newest package versions
to reduce the risk of issues.
2. If you are still running a 13.0 profile, select gcc 6.4.0 or later
as the system compiler, source /etc/profile and reinstall libtool:
# gcc-config -l
[1] x86_64-pc-linux-gnu-5.5.0 *
[2] x86_64-pc-linux-gnu-8.3.0
# gcc-config 2
# . /etc/profile
# emerge -1v libtool
3. Install the tool:
# emerge -1v app-portage/unsymlink-lib
4. Run 'unsymlink-lib --analyze' and check the output for obvious
mistakes. If you need to perform any changes to the system, remember
to run 'unsymlink-lib --analyze' again afterwards.
[past this point do not call emerge or modify /usr manually]
5. This is a very good time to make a backup.
6. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see
what is going to happen.
7. Reboot your system. Check if important programs work.
In particular, verify that e.g. 'emerge --info' works (but do not
install anything). If you hit any serious problems, you can use
'unsymlink-lib --rollback' to revert the changes and return to
step 3.
8. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see
what is going to happen but note that you're going to see a very long
list of files to remove.
9. Switch the profile, e.g.:
# eselect profile set default/linux/amd64/17.1/desktop
[at this point you can start using emerge again. emerge will then
not display this message anymore, but the remaining steps are still
required!]
10. Rebuild the toolchain:
# emerge -1v sys-devel/gcc:9.3.0
[ repeat for other slots you will be using ]
[ if you are upgrading from 13.0 profile, also: ]
# emerge -1v sys-devel/binutils
# emerge -1v sys-libs/glibc
11. If you are using a multilib profile, rebuild all 32-bit packages.
This can be done using:
# emerge -1v --deep /lib32 /usr/lib32 /usr/lib/llvm/*/lib32
Alternatively, if you are switching from one of the 13.0 profiles
you can rebuild all packages as detailed in the 17.0 news item:
# emerge -ev @world
12. Once the last 32-bit package is rebuilt, your package manager
should remove the orphaned /lib32 and /usr/lib32 symlinks. If that
does not happen, remove them manually:
# rm /lib32 /usr/lib32
For known issues, please see bug #506276 [1]. If you have any problems
with the new profiles or the migration procedure, please report a bug
and make it block the tracker.
[1] bug #506276
[2] https://www.gentoo.org/support/news-items/2019-06-05-amd64-17-1-profiles-are-now-stable.html
Portage 3.0.30 (python 3.9.9-final-0, default/linux/amd64/17.0, gcc-11.2.0, glibc-2.33-r7, 3.14.32-xxxx-std+acct-ipv6-64 x86_64)
=================================================================
System uname: Linux-3.14.32-xxxx-std+acct-ipv6-64-x86_64-Intel-R-_Core-TM-_i7_CPU_920_@_2.67GHz-with-glibc2.33
KiB Mem: 8226180 total, 474792 free
KiB Swap: 8191992 total, 7745696 free
sh bash 5.1_p16
ld GNU ld (Gentoo 2.37_p1 p0) 2.37
ccache version 4.5.1 [disabled]
app-misc/pax-utils: 1.3.3::gentoo
app-shells/bash: 5.1_p16::gentoo
dev-lang/perl: 5.34.0-r6::gentoo
dev-lang/python: 2.7.18_p13::gentoo, 3.6.15::gentoo, 3.7.12_p1::gentoo, 3.9.9-r1::gentoo, 3.10.0_p1-r1::gentoo
dev-util/ccache: 4.5.1::gentoo
dev-util/cmake: 3.22.2::gentoo
dev-util/meson: 0.60.3::gentoo
sys-apps/baselayout: 2.7-r3::gentoo
sys-apps/openrc: 0.44.10::gentoo
sys-apps/sandbox: 2.25::gentoo
sys-devel/autoconf: 2.69-r4::gentoo, 2.71-r1::gentoo
sys-devel/automake: 1.11.6-r2::gentoo, 1.15.1-r2::gentoo, 1.16.4::gentoo
sys-devel/binutils: 2.30-r2::gentoo, 2.31.1-r6::gentoo, 2.37_p1::gentoo
sys-devel/binutils-config: 5.4::gentoo
sys-devel/gcc: 9.4.0::gentoo, 11.2.0::gentoo
sys-devel/gcc-config: 2.5-r1::gentoo
sys-devel/libtool: 2.4.6-r6::gentoo
sys-devel/make: 4.3::gentoo
sys-kernel/linux-headers: 5.15-r3::gentoo (virtual/os-headers)
sys-libs/glibc: 2.33-r7::gentoo
Repositories:
gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-verify-metamanifest: yes
sync-rsync-verify-jobs: 1
sync-rsync-extra-opts:
sync-rsync-verify-max-age: 24
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php7.3/ext-active/ /etc/php/apache2-php8.0/ext-active/ /etc/php/cgi-php7.3/ext-active/ /etc/php/cgi-php8.0/ext-active/ /etc/php/cli-php7.3/ext-active/ /etc/php/cli-php8.0/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--nospinner"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news nostrip parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://gentoo.mirrors.ovh.net/gentoo-distfiles/"
LANG="C"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j3"
PKGDIR="/var/cache/binpkgs"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
SHELL="/bin/ksh"
USE="acl amd64 bzip2 cli crypt dri fortran gdbm iconv ipv6 libglvnd libtirpc multilib ncurses nls nptl openmp pam pcre readline seccomp split-usr ssl unicode xattr zlib" ABI_X86="64" ADA_TARGET="gnat_2020" APACHE2_MODULES="ext_filter authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user access auth auth_dbm auth_anon auth_digest alias cgid file-cache echo charset-lite cache disk-cache mem-cache ext-filter case_filter case-filter-in deflate filter mime-magic cern-meta expires headers usertrack unique-id proxy proxy-connect proxy-ftp proxy-http info include cgi cgid dav dav-fs vhost-alias speling rewrite log_config logio env setenvif mime status autoindex asis negotiation dir imap actions userdir so unique_id" APACHE2_MPMS="peruser itk" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-4 php8-0" POSTGRES_TARGETS="postgres12 postgres13" PYTHON_SINGLE_TARGET="python3_9" PYTHON_TARGETS="python3_9" RUBY_TARGETS="ruby26 ruby27" USERLAND="GNU" VIDEO_CARDS="amdgpu fbdev intel nouveau radeon radeonsi vesa dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LEX, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS
]0;root@:/usr/portage]0;emerge
!!! Your current profile is deprecated and not supported anymore.
!!! Use eselect profile to update your profile.
!!! Please upgrade to the following profile if possible:
default/linux/amd64/17.1
To upgrade do the following steps:
The amd64 17.1 profiles switch to a more standard 'no SYMLINK_LIB'
multilib layout, and require an explicit migration. The migration is
performed using the app-portage/unsymlink-lib tool.
Read the Gentoo news item [2] for more information!
The following steps can be used to upgrade your system:
1. Sync and upgrade your system to the newest package versions
to reduce the risk of issues.
2. If you are still running a 13.0 profile, select gcc 6.4.0 or later
as the system compiler, source /etc/profile and reinstall libtool:
# gcc-config -l
[1] x86_64-pc-linux-gnu-5.5.0 *
[2] x86_64-pc-linux-gnu-8.3.0
# gcc-config 2
# . /etc/profile
# emerge -1v libtool
3. Install the tool:
# emerge -1v app-portage/unsymlink-lib
4. Run 'unsymlink-lib --analyze' and check the output for obvious
mistakes. If you need to perform any changes to the system, remember
to run 'unsymlink-lib --analyze' again afterwards.
[past this point do not call emerge or modify /usr manually]
5. This is a very good time to make a backup.
6. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see
what is going to happen.
7. Reboot your system. Check if important programs work.
In particular, verify that e.g. 'emerge --info' works (but do not
install anything). If you hit any serious problems, you can use
'unsymlink-lib --rollback' to revert the changes and return to
step 3.
8. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see
what is going to happen but note that you're going to see a very long
list of files to remove.
9. Switch the profile, e.g.:
# eselect profile set default/linux/amd64/17.1/desktop
[at this point you can start using emerge again. emerge will then
not display this message anymore, but the remaining steps are still
required!]
10. Rebuild the toolchain:
# emerge -1v sys-devel/gcc:9.3.0
[ repeat for other slots you will be using ]
[ if you are upgrading from 13.0 profile, also: ]
# emerge -1v sys-devel/binutils
# emerge -1v sys-libs/glibc
11. If you are using a multilib profile, rebuild all 32-bit packages.
This can be done using:
# emerge -1v --deep /lib32 /usr/lib32 /usr/lib/llvm/*/lib32
Alternatively, if you are switching from one of the 13.0 profiles
you can rebuild all packages as detailed in the 17.0 news item:
# emerge -ev @world
12. Once the last 32-bit package is rebuilt, your package manager
should remove the orphaned /lib32 and /usr/lib32 symlinks. If that
does not happen, remove them manually:
# rm /lib32 /usr/lib32
For known issues, please see bug #506276 [1]. If you have any problems
with the new profiles or the migration procedure, please report a bug
and make it block the tracker.
[1] bug #506276
[2] https://www.gentoo.org/support/news-items/2019-06-05-amd64-17-1-profiles-are-now-stable.html
These are the packages that would be merged, in order:
Calculating dependencies ... done!
[ebuild N ] dev-perl/DBD-mysql-4.50.0-r1::gentoo USE="mysql ssl (-mariadb) -test" 0 KiB
Total: 1 package (1 new), Size of downloads: 0 KiB
>>> Verifying ebuild manifestsE
>>> Emerging (1 of 1) dev-perl/DBD-mysql-4.50.0-r1::gentooE]0;emerge: (1 of 1) dev-perl/DBD-mysql-4.50.0-r1 Clean * DBD-mysql-4.050.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ]
]0;emerge: (1 of 1) dev-perl/DBD-mysql-4.50.0-r1 Compile>>> Unpacking source...
>>> Unpacking DBD-mysql-4.050.tar.gz to /var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/work
>>> Source unpacked in /var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/work
>>> Preparing source in /var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/work/DBD-mysql-4.050 ...
* Applying DBD-mysql-4.050-no-dot-inc.patch ...
[ ok ]
* Applying DBD-mysql-4.050-fix-float-type-conversion.patch ...
[ ok ]
* Applying DBD-mysql-4.050-fix-for-MariaDB-10.3.13-with-zerofil.patch ...
[ ok ]
* Removing un-needed t/pod.t
* Removing un-needed t/manifest.t
* Fixing Manifest
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/work/DBD-mysql-4.050 ...
* Using ExtUtils::MakeMaker
* perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none DESTDIR=/var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/image --ssl --mysql_config=/usr/bin/mysql_config
PLEASE NOTE:
For 'make test' to run properly, you must ensure that the
database user '' can connect to your MySQL server
and has the proper privileges that these tests require such
as 'drop table', 'create table', 'drop procedure', 'create procedure'
as well as others.
mysql> grant all privileges on test.* to ''@'localhost' identified by 's3kr1t';
You can also optionally set the user to run 'make test' with:
perl Makefile.PL --testuser=username
I will use the following settings for compiling and testing:
cflags (mysql_config) = -I/usr/include/mysql
embedded (guessed ) =
ldflags (guessed ) =
libs (mysql_config) = -L/usr/lib64 -lmysqlclient -lpthread -ldl -lz -lzstd -lssl -lcrypto -lresolv -lm -lrt
mysql_config (Users choice) = /usr/bin/mysql_config
nocatchstderr (default ) = 0
nofoundrows (default ) = 0
nossl (default ) = 0
testdb (default ) = test
testhost (default ) =
testpassword (default ) =
testport (default ) =
testsocket (default ) =
testuser (guessed ) =
To change these settings, see 'perl Makefile.PL --help' and
'perldoc DBD::mysql::INSTALL'.
Checking if libs are available for compiling...
Can't link/include C library 'mysqlclient', aborting.
* ERROR: dev-perl/DBD-mysql-4.50.0-r1::gentoo failed (configure phase):
* Unable to build!
*
* Call stack:
* ebuild.sh, line 127: Called src_configure
* environment, line 1146: Called perl-module_src_configure
* environment, line 655: Called die
* The specific snippet of code:
* perl Makefile.PL "$@" <<< "${pm_echovar}" || die "Unable to build!";
*
* If you need support, post the output of `emerge --info '=dev-perl/DBD-mysql-4.50.0-r1::gentoo'`,
* the complete build log and the output of `emerge -pqv '=dev-perl/DBD-mysql-4.50.0-r1::gentoo'`.
* The complete build log is located at '/var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/temp/environment'.
* Working directory: '/var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/work/DBD-mysql-4.050'
* S: '/var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/work/DBD-mysql-4.050'
>>> Failed to emerge dev-perl/DBD-mysql-4.50.0-r1, Log file:E
>>> '/var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/temp/build.log'E
* Messages for package dev-perl/DBD-mysql-4.50.0-r1:
* ERROR: dev-perl/DBD-mysql-4.50.0-r1::gentoo failed (configure phase):
* Unable to build!
*
* Call stack:
* ebuild.sh, line 127: Called src_configure
* environment, line 1146: Called perl-module_src_configure
* environment, line 655: Called die
* The specific snippet of code:
* perl Makefile.PL "$@" <<< "${pm_echovar}" || die "Unable to build!";
*
* If you need support, post the output of `emerge --info '=dev-perl/DBD-mysql-4.50.0-r1::gentoo'`,
* the complete build log and the output of `emerge -pqv '=dev-perl/DBD-mysql-4.50.0-r1::gentoo'`.
* The complete build log is located at '/var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/temp/environment'.
* Working directory: '/var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/work/DBD-mysql-4.050'
* S: '/var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/work/DBD-mysql-4.050'
]0;root@:/usr/portage
Script done on 2022-02-16 00:03:05+01:00 [COMMAND_EXIT_CODE="1"]
|
On 17.1 new machine everything works and DBD-mysql installs fine with mysql-connector-c
After some troubleshooting (perl Makefile.PL being unable to find -lstdc++ at all while using "gcc" as a compiler/linker), I have tracked this down to this minimal test case:
On 17.0:
| Code: |
# echo 'int main(){return 0;}' > t.c && g++ -c t.c && gcc t.o -lasprintf
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libstdc++.so.6, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libasprintf.so, not found (try using -rpath or -rpath-link)
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libasprintf.so: undefined reference to `operator new[](unsigned long)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libasprintf.so: undefined reference to `std::ios_base::Init::~Init()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libasprintf.so: undefined reference to `std::ios_base::Init::Init()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libasprintf.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21'
collect2: error: ld returned 1 exit status
# gcc-config -l
[1] x86_64-pc-linux-gnu-9.4.0
[2] x86_64-pc-linux-gnu-11.2.0 *
# eselect binutils list
[1] x86_64-pc-linux-gnu-2.30
[2] x86_64-pc-linux-gnu-2.31.1
[3] x86_64-pc-linux-gnu-2.37_p1 *
|
(I am using libasprintf.so here because it also links to C++ runtime library and to show it has little to do with MySQL complexities)
On 17.1:
| Code: |
# echo 'int main(){return 0;}' > t.c && g++ -c t.c && gcc t.o -lasprintf
# echo $?
0
# ./a.out; echo $?
0
# gcc-config -l
[1] x86_64-pc-linux-gnu-11.2.0 *
# eselect binutils list
[1] x86_64-pc-linux-gnu-2.37_p1 *
|
Now using g++ for linking of course works (this is on the "old" machine)
| Code: |
# echo 'int main(){return 0;}' > t.c && g++ -c t.c && g++ t.o -lasprintf
# ./a.out; echo $?
0
|
It is clear to me that using g++ to link C++ code is actually the only correct way to do this.
It looks like, however, using gcc to link C++ libraries (even without the dreaded -lstdc++) may work under some circumstances and I do not understand why.
Besides, dev-perl/DBD-mysql has to use gcc and not g++ because iit invokes the compiler that built Perl and it seems to be pretty hard to convice Perl extension building system to use something else.
If g++ is the only correct way, why dev-perl/DBD-mysql C code extension linking to C++ libraries works (on a "clean" machine)?
If gcc linking C++ libraries has a chance to work, how can I bring that wonder to the "old" machine? |
|
| Back to top |
|
 |
sam_
Developer
Joined: 14 Aug 2020
Posts: 1721
|
| Posted: Wed Feb 16, 2022 12:55 am Post subject: |
|
|
Perl calcifies a bunch of stuff at build time and a lot of Perl modules use that environment. Can you verify you haven't set CC, CXX, etc in make.conf, then try emerge -v1 dev-lang/perl then emerge -v1 dev-perl/Module-Build? We may need to try rebuilding some others too.
I find it odd that it's latching on to using gcc to link C++. I might be missing something though.
Good job on your investigation so far. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9714
Location: almost Mile High in the USA
|
| Posted: Wed Feb 16, 2022 1:16 am Post subject: |
|
|
Also try rebuilding --oneshot sys-devel/gettext if it hasn't already to see if the testcase will fix itself...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
saperski
n00b
Joined: 15 Feb 2022
Posts: 9
|
| Posted: Wed Feb 16, 2022 9:29 am Post subject: |
|
|
| eccerr0r wrote: | | Also try rebuilding --oneshot sys-devel/gettext if it hasn't already to see if the testcase will fix itself... |
Thank you, unfortunately it does not:
| Code: |
# ls -ld /usr/lib64/libasprintf*
lrwxrwxrwx 1 root root 20 Feb 16 10:23 /usr/lib64/libasprintf.so -> libasprintf.so.0.0.0
lrwxrwxrwx 1 root root 20 Feb 16 10:23 /usr/lib64/libasprintf.so.0 -> libasprintf.so.0.0.0
-rwxr-xr-x 1 root root 16776 Feb 16 10:23 /usr/lib64/libasprintf.so.0.0.0
# echo 'int main(){return 0;}' > t.c && g++ -c t.c && gcc t.o -lasprintf
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libstdc++.so.6, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libasprintf.so, not found (try using -rpath or -rpath-link)
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libasprintf.so: undefined reference to `operator new[](unsigned long)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libasprintf.so: undefined reference to `std::ios_base::Init::~Init()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libasprintf.so: undefined reference to `std::ios_base::Init::Init()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libasprintf.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21'
collect2: error: ld returned 1 exit status
|
libasprintf.so looks perfectly fine as before:
| Code: |
# ldd /usr/lib64/libasprintf.so
linux-vdso.so.1 (0x00007fffb27e2000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so.6 (0x00007f059a14a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0599f90000)
libm.so.6 => /lib64/libm.so.6 (0x00007f0599e50000)
/lib64/ld-linux-x86-64.so.2 (0x00007f059a366000)
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libgcc_s.so.1 (0x00007f0599e36000)
|
|
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9714
Location: almost Mile High in the USA
|
| Posted: Wed Feb 16, 2022 5:39 pm Post subject: |
|
|
I still have an old 17.0 box and the test case works fine on it as a data point... This issue is weird, inconsistent...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
larrys
Tux's lil' helper
Joined: 20 Jul 2020
Posts: 81
Location: New Jersey
|
| Posted: Thu Feb 17, 2022 12:14 am Post subject: |
|
|
saperski,
I noticed you had 2 versions of gcc installed in your emerge --info. I googled "gcc not finding stdlibc++", and the first hit I got was https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths It says in part | Quote: | If you already have an older version of libstdc++ installed then the error might look like one of the following instead:
./a.out: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found
./a.out: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.8' not found
This means the linker found /usr/lib/libstdc++.so.6 but that library belongs to an older version of GCC than was used to compile and link the program a.out (or some part of it). The program depends on code defined in the newer libstdc++ that belongs to the newer version of GCC, so the linker must be told how to find the newer libstdc++ shared library. |
I don't know if that's your problem, but it sounded like it was worth checking. |
|
| Back to top |
|
|
saperski
n00b
Joined: 15 Feb 2022
Posts: 9
|
| Posted: Thu Feb 17, 2022 11:59 am Post subject: |
|
|
| larrys wrote: | ./a.out: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found
./a.out: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.8' not found
|
Thank you, that was my concern, too.
But Gentoo does things differently, as there is no /usr/lib/libstdc++.so.6:
| Code: |
# find /usr/lib/libstd* /usr/lib64/libstd*
find: '/usr/lib/libstd*': No such file or directory
find: '/usr/lib64/libstd*': No such file or directory
# find /usr/lib64/gcc -name libstdc++.so.6
/usr/lib64/gcc/x86_64-pc-linux-gnu/9.4.0/32/libstdc++.so.6
/usr/lib64/gcc/x86_64-pc-linux-gnu/9.4.0/libstdc++.so.6
/usr/lib64/gcc/x86_64-pc-linux-gnu/11.2.0/32/libstdc++.so.6
/usr/lib64/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so.6
|
And the libraries are linked correctly:
| Code: |
# ldd /usr/lib64/libasprintf.so
linux-vdso.so.1 (0x00007fffb495b000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so.6 (0x00007f0a6c068000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0a6beae000)
libm.so.6 => /lib64/libm.so.6 (0x00007f0a6bd6e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0a6c284000)
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libgcc_s.so.1 (0x00007f0a6bd54000)
# ldd /usr/lib64/libmysqlclient.so
linux-vdso.so.1 (0x00007fff612e4000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007eff88704000)
libz.so.1 => /lib64/libz.so.1 (0x00007eff886ea000)
libzstd.so.1 => /usr/lib64/libzstd.so.1 (0x00007eff885db000)
libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007eff88549000)
libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007eff8828a000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007eff88271000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007eff8824f000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so.6 (0x00007eff88041000)
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libgcc_s.so.1 (0x00007eff88027000)
libc.so.6 => /lib64/libc.so.6 (0x00007eff87e6d000)
/lib64/ld-linux-x86-64.so.2 (0x00007eff88d91000)
libm.so.6 => /lib64/libm.so.6 (0x00007eff87d2d000)
# ls -ldF /usr/lib64 /usr/lib /lib /lib64
drwxr-xr-x 10 root root 7168 Feb 15 22:02 /lib/
drwxr-xr-x 10 root root 7168 Feb 15 22:02 /lib64/
drwxr-xr-x 63 root root 73728 Feb 16 10:23 /usr/lib/
drwxr-xr-x 63 root root 73728 Feb 16 10:23 /usr/lib64/
|
|
|
| Back to top |
|
|
saperski
n00b
Joined: 15 Feb 2022
Posts: 9
|
| Posted: Thu Feb 17, 2022 1:27 pm Post subject: |
|
|
First, my most important config files:
My /etc/make.conf:
| Code: |
# grep -v '^#' /etc/make.conf| grep -v '^ *$'
COMMON_FLAGS="-O2 -pipe"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
GENTOO_MIRRORS="http://gentoo.mirrors.ovh.net/gentoo-distfiles/"
EMERGE_DEFAULT_OPTS="--nospinner"
MAKEOPTS="-j3"
PORTAGE_ELOG_CLASSES="log warn error"
NOCOLOR=yes
MAILMAN_VER_PREFIX=/usr/home/mailman
APACHE2_MODULES="ext_filter authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user access auth auth_dbm auth_anon auth_digest alias cgid file-cache echo charset-lite cache disk-cache mem-cache ext-filter case_filter case-filter-in deflate filter mime-magic cern-meta expires headers usertrack unique-id proxy proxy-connect proxy-ftp proxy-http info include cgi cgid dav dav-fs vhost-alias speling rewrite log_config logio env setenvif mime status autoindex asis negotiation dir imap actions userdir so unique_id"
APACHE2_MPMS="peruser itk"
FEATURES="splitdebug nostrip"
ACCEPT_LICENSE="*"
PORTDIR="/usr/portage"
|
(I think the "itk" addition has not been tested yet)
My package.use:
| Code: |
app-crypt/libb2 -openmp
app-editors/emacs tiff svg source kerberos gzip-el
app-editors/nano spell
app-misc/mc chdir unicode
app-misc/screen nethack
app-text/djvu xml tiff
app-text/ghostscript-gpl -cups
app-text/tesseract tiff
dev-db/postgresql kerberos threads -perl uuid xml -python -pam -nls
dev-java/icedtea-bin -cups
app-eselect/eselect-php apache2
dev-lang/php apache2 bcmath ctype curl filter -gd-external gd json math mysql mysqli postgres pcre session xml xmlreader xmlwriter simplexml zip mysqlnd debug json pdo sqlite3 exif cdb wddx sqlite intl tidy
dev-libs/apr-util -mysql
dev-libs/boost context
dev-libs/jemalloc stats
gnome-base/librsvg -gtk
mail-mta/postfix -mysql
media-gfx/graphviz python
media-gfx/imagemagick gs raw svg tiff xml djvu
media-libs/libflac ogg
media-libs/speex ogg
media-video/ffmpeg gsm speex vpx xvid rtmp vorbis theora mp3 x264 amr
media-video/ffmpeg2theora kate
net-libs/c-client chappa
net-misc/oidentd ipv6
net-misc/openssh kerberos
sys-apps/man -nls
sys-boot/grub -truetype ncurses -fonts -nls -themes
sys-devel/gcc gcj cxx
sys-devel/gdb -nls
virtual/ffmpeg mp3 theora x264
www-apps/wordpress vhosts
www-servers/apache suexec apache2_modules_unixd apache2_modules_authn_core apache2_modules_authz_core apache2_modules_socache_shmcb
x11-libs/cairo -X
dev-perl/Template-Toolkit -mysql
dev-db/mysql -perl
sys-apps/man-db -manpager
|
Now on to Perl:
| Quote: | | emerge -v1 dev-lang/perl then emerge -v1 dev-perl/Module-Build? We may need to try rebuilding some others too. |
Tried this. Perl and Module::Build emerged fine, but afterwards portage demanded to have more:
Full log is here: https://ylog.eu/tmp/after-forum-post-3.log
It wants to install some additional packages like xemacs (why?) and fails with building audiofile for pretty much the same reason (not able to link libstdc++.so.6) that we investigate here.
| Quote: | | I find it odd that it's latching on to using gcc to link C++. I might be missing something though. |
I don't even think that Perl can do this. Somehow we get away with using C compiler/linker improperly?
| Quote: | | Good job on your investigation so far. |
Thank you for your wiki pages explaining how to fix portage breakdown and the like. This was the most useful single piece of information I found during this journey. I wish the catalogue of portage "mishaps" on the way was a part of the official handbook. It's third time I am doing something similar to this (upgrading a few-year-old Gentoo box) and the usual staging update method does no longer work - for the period 2018-2020 it is very hard to find some Gentoo-specific distfiles, they get deleted pretty quickly for example from the @mgorny account and are very hard to find. I spent more time chasing distfiles than fixing actual upgrade problems. The solution was to unmerge as much as I could, fast forward to the present and solve the portage quirks with Sam's guide. Big thank you!
But here is one more thing - how I got more information from the DBD::mysql failure. After failed emerge we have a work directory and then:
| Code: |
# cd /var/tmp/portage/dev-perl/DBD-mysql-4.50.0-r1/work/DBD-mysql-4.050
# ed Makefile.PL
32694
/assert_lib
assert_lib(
+
LIBS => ($opt->{'embedded'} ? $opt->{'embedded'} : $opt->{libs}),
a
debug => 1
.
-4,+1p
print "Checking if libs are available for compiling...\n";
assert_lib(
LIBS => ($opt->{'embedded'} ? $opt->{'embedded'} : $opt->{libs}),
debug => 1
);
w
32707
q
# perl Makefile.PL
PLEASE NOTE:
For 'make test' to run properly, you must ensure that the
database user 'root' can connect to your MySQL server
and has the proper privileges that these tests require such
as 'drop table', 'create table', 'drop procedure', 'create procedure'
as well as others.
mysql> grant all privileges on test.* to 'root'@'localhost' identified by 's3kr1t';
You can also optionally set the user to run 'make test' with:
perl Makefile.PL --testuser=username
I will use the following settings for compiling and testing:
cflags (mysql_config) = -I/usr/include/mysql
embedded (guessed ) =
ldflags (guessed ) =
libs (mysql_config) = -L/usr/lib64 -lmysqlclient -lpthread -ldl -lz -lzstd -lssl -lcrypto -lresolv -lm -lrt
mysql_config (guessed ) = mysql_config
nocatchstderr (default ) = 0
nofoundrows (default ) = 0
nossl (default ) = 0
testdb (default ) = test
testhost (default ) =
testpassword (default ) =
testport (default ) =
testsocket (default ) =
testuser (guessed ) = root
To change these settings, see 'perl Makefile.PL --help' and
'perldoc DBD::mysql::INSTALL'.
Checking if libs are available for compiling...
# Compiler seems to be /usr/bin/x86_64-pc-linux-gnu-gcc
# /usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 assertlibnH0qd2Xe.c -L/usr/lib64 -lmysqlclient -o assertlibkfPdXAGD
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libstdc++.so.6, needed by /usr/lib64/libmysqlclient.so, not found (try using -rpath or -rpath-link)
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `VTT for std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `vtable for std::basic_streambuf<char, std::char_traits<char> >@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `__cxa_allocate_exception@CXXABI_1.3'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::bad_alloc::~bad_alloc()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__throw_system_error(int)@GLIBCXX_3.4.11'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__detail::_List_node_base::_M_unhook()@GLIBCXX_3.4.15'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_append(char const*, unsigned long)@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)@GLIBCXX_3.4.9'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `__cxa_throw@CXXABI_1.3'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `operator delete(void*, std::nothrow_t const&)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::locale::locale()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::_Rb_tree_decrement(std::_Rb_tree_node_base*)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `vtable for std::__cxx11::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `vtable for std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@GLIBCXX_3.4.15'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_assign(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned long) const@GLIBCXX_3.4.18'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `operator new(unsigned long)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::locale::~locale()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__throw_logic_error(char const*)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::nothrow@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `vtable for __cxxabiv1::__class_type_info@CXXABI_1.3'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `__cxa_end_catch@CXXABI_1.3'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `__cxa_rethrow@CXXABI_1.3'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base*)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__once_call@GLIBCXX_3.4.11'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long, unsigned long, char const*, unsigned long)@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::ios_base::ios_base()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `operator new(unsigned long, std::nothrow_t const&)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::_Hash_bytes(void const*, unsigned long, unsigned long)@CXXABI_1.3.5'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `vtable for std::basic_ios<char, std::char_traits<char> >@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__once_callable@GLIBCXX_3.4.11'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `__once_proxy@GLIBCXX_3.4.11'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::basic_istream<char, std::char_traits<char> >& std::getline<char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char)@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::ios_base::Init::Init()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `__gxx_personality_v0@CXXABI_1.3'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::ios_base::Init::~Init()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `operator delete[](void*)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `typeinfo for std::bad_alloc@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned long, unsigned long, unsigned long) const@GLIBCXX_3.4.18'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__cxx11::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::_M_sync(char*, unsigned long, unsigned long)@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(unsigned long, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info@CXXABI_1.3'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__throw_length_error(char const*)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `__cxa_begin_catch@CXXABI_1.3'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::ios_base::~ios_base()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `operator new[](unsigned long)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `operator delete(void*, unsigned long)@CXXABI_1.3.9'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__throw_bad_alloc()@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__throw_bad_array_new_length()@GLIBCXX_3.4.29'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::find(char const*, unsigned long, unsigned long) const@GLIBCXX_3.4.21'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `vtable for std::bad_alloc@GLIBCXX_3.4'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmysqlclient.so: undefined reference to `std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_stringstream()@GLIBCXX_3.4.21'
collect2: error: ld returned 1 exit status
# /usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 assertlibnH0qd2Xe.c -L/usr/lib64 -lpthread -o assertlibg6vurUR4
# /usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 assertlibnH0qd2Xe.c -L/usr/lib64 -ldl -o assertlibEY_UX4HI
# /usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 assertlibnH0qd2Xe.c -L/usr/lib64 -lz -o assertlibj3kHk71j
# /usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 assertlibnH0qd2Xe.c -L/usr/lib64 -lzstd -o assertlibbIqklc8y
# /usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 assertlibnH0qd2Xe.c -L/usr/lib64 -lssl -o assertlibY5zwXL6u
# /usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 assertlibnH0qd2Xe.c -L/usr/lib64 -lcrypto -o assertlibBAuHAuMH
# /usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 assertlibnH0qd2Xe.c -L/usr/lib64 -lresolv -o assertlibcUncZibe
# /usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 assertlibnH0qd2Xe.c -L/usr/lib64 -lm -o assertlibJKdEk6f0
# /usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 assertlibnH0qd2Xe.c -L/usr/lib64 -lrt -o assertlibeXY1mDtN
Can't link/include C library 'mysqlclient', aborting.
|
|
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9714
Location: almost Mile High in the USA
|
| Posted: Thu Feb 17, 2022 5:00 pm Post subject: |
|
|
Yes Gentoo sort of puts libstc++ in a different place to support slotting of gcc - have multiple versions installed at the same time.
Did you do anything special to install gcc-11?
Could you let portage install gcc-10 in its slot temporarily and see its behavior as an experiment?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
saperski
n00b
Joined: 15 Feb 2022
Posts: 9
|
| Posted: Thu Feb 17, 2022 5:22 pm Post subject: |
|
|
| eccerr0r wrote: |
Could you let portage install gcc-10 in its slot temporarily and see its behavior as an experiment? |
Sure, I think I've tried with gcc-9 and older binutils but I can try with gcc-10. Which binutils version shall I use?
One thing I also noticed (this might be actually a bug) that regardless of "eselect gcc" version C++ libraries were compiled with the highest installed g++ version, in my case 11.2.0 |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9714
Location: almost Mile High in the USA
|
| Posted: Thu Feb 17, 2022 5:47 pm Post subject: |
|
|
I sort of try to avoid gcc9 after running into an unrelated issue with it (though it was also a linking issue)... but it also doesn't do the right thing?
That seems to indeed be a bug, it should use the g++ of the gcc version that's selected...but you need to make sure you re-source the environment every time you change the default compiler version.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
saperski
n00b
Joined: 15 Feb 2022
Posts: 9
|
| Posted: Thu Feb 17, 2022 10:17 pm Post subject: Linker scripts |
|
|
To go further, I have asked the linker to produce linker scripts used and some verbose output. I haven't analyzed them now but the differences might be interesting.
A test case is different now - to actually try to use the linked library.
Old machine, gcc linking
| Code: |
printf '#include <mysql/mysql.h>\nint main(){mysql_init(NULL);return 201;}'>t.c && gcc -c t.c && gcc t.o -lmysqlclient -Wl,--verbose > /tmp/linker.1
|
New machine, gcc linking
| Code: |
printf '#include <mysql/mysql.h>\nint main(){mysql_init(NULL);return 201;}'>t.c && gcc -c t.c && gcc t.o -lmysqlclient -Wl,--verbose > /tmp/linker.2
|
Old machine, g++ linking
| Code: |
printf '#include <mysql/mysql.h>\nint main(){mysql_init(NULL);return 201;}'>t.c && gcc -c t.c && g++ t.o -lmysqlclient -Wl,--verbose > /tmp/linker.3
|
New machine, g++ linking
| Code: |
printf '#include <mysql/mysql.h>\nint main(){mysql_init(NULL);return 201;}'>t.c && gcc -c t.c && g++ t.o -lmysqlclient -Wl,--verbose > /tmp/linker.4
|
Additionally, the "gcc -c t.c" command seems to produce identical object file for both systems (sha256 b4394abb6cdb189176c22af45318ba3bc8be424208accd09d0590695c8d48c6f) |
|
| Back to top |
|
|
saperski
n00b
Joined: 15 Feb 2022
Posts: 9
|
| Posted: Fri Feb 18, 2022 10:29 am Post subject: |
|
|
Good news that gcc compilation on the "old box" recognizes the need to link libstdc++
libstdc++.so.6 needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libmysqlclient.so
but then the "old box" simply cannot locate it in the /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so location:
attempt to open /usr/x86_64-pc-linux-gnu/lib64/libstdc++.so.6 failed
attempt to open /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p164/libstdc++.so.6 failed
attempt to open /usr/local/lib64/libstdc++.so.6 failed
attempt to open /lib64/libstdc++.so.6 failed
attempt to open /usr/lib64/libstdc++.so.6 failed
attempt to open /usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6 failed
attempt to open /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1/libstdc++.so.6 failed
attempt to open /usr/local/lib/libstdc++.so.6 failed
attempt to open /lib/libstdc++.so.6 failed
attempt to open /usr/lib/libstdc++.so.6 failed
attempt to open /usr/x86_64-pc-linux-gnu/lib64/libstdc++.so.6 failed
attempt to open /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p164/libstdc++.so.6 failed
attempt to open /usr/local/lib64/libstdc++.so.6 failed
attempt to open /lib64/libstdc++.so.6 failed
attempt to open /usr/lib64/libstdc++.so.6 failed
attempt to open /usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6 failed
attempt to open /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1/libstdc++.so.6 failed
attempt to open /usr/local/lib/libstdc++.so.6 failed
attempt to open /lib/libstdc++.so.6 failed
attempt to open /usr/lib/libstdc++.so.6 failed
For g++ compilation on the "old box" and for both gcc and g++ compilations on the "new box" this is no problem:
attempt to open /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so
I have also generated "gcc -v" or "g++ -v" output from the linking stage and there are no differences how collect2 is invoked between the "old" and the "new" box.
Implicit paths given to collect2 in all four cases look like this
| Code: |
-L/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0
-L/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64
-L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../..
|
so it seems that collect2 gets "-L" path provided, among others, with the directory where libstdc++.so.6 lives.
SEARCH_DIR in the linker script is also the same and is quite uninteresting:
| Code: |
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64");
SEARCH_DIR("/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p164");
SEARCH_DIR("/usr/local/lib64");
SEARCH_DIR("/lib64");
SEARCH_DIR("/usr/lib64");
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib");
SEARCH_DIR("/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1");
SEARCH_DIR("/usr/local/lib");
SEARCH_DIR("/lib");
SEARCH_DIR("/usr/lib");
|
This command
| Code: |
ln -s /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so* /usr/local/lib/
|
seems to work around the issue and lets me build DBD::mysql
So the question could be, why the "-L/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0" flag being given to collect2 does not help the linker to find the libstdc++.so.6 there? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21920
|
| Posted: Fri Feb 18, 2022 4:26 pm Post subject: |
|
|
| -L tells the linker to search the directory when resolving a -l link request. Your gcc is not passing -lstdc++ to request such a link, so the -L has no effect. As the error itself hints, -rpath can adjust the search path that is used for finding libstdc++. However, I would have expected that since libmysqlclient.so already needs libstdc++, and the compiler does not use -lstdc++, that this should have done the right thing without user intervention. I wonder if this is somehow related to using the old 17.0 profile. Perhaps gcc or binutils were configured with paths that are only correct after the profile migration. |
|
| Back to top |
|
|
saperski
n00b
Joined: 15 Feb 2022
Posts: 9
|
| Posted: Fri Feb 18, 2022 4:45 pm Post subject: |
|
|
| Hu wrote: | | -L tells the linker to search the directory when resolving a -l link request. Your gcc is not passing -lstdc++ to request such a link, so the -L has no effect. As the error itself hints, -rpath can adjust the search path that is used for finding libstdc++. However, I would have expected that since libmysqlclient.so already needs libstdc++, and the compiler does not use -lstdc++, that this should have done the right thing without user intervention. |
From the libstdc++.so.6 needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libmysqlclient.so I'd judge that even though gcc and not g++ compiler got invoked and no -lstd++ flag was set the linker was able to figure out that libstdc++.so.6 needs to be added.
| Quote: | | I wonder if this is somehow related to using the old 17.0 profile. Perhaps gcc or binutils were configured with paths that are only correct after the profile migration. |
That's where I need help from Gentoo experts. I have no clue where to look for it.
Looking at /etc/env.d/gcc/x86_64-pc-linux-gnu-11.2.0 I see on the 17.0 box
| Code: |
GCC_PATH="/usr/x86_64-pc-linux-gnu/gcc-bin/11.2.0"
LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0:/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/32"
MANPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.0/man"
INFOPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.0/info"
STDCXX_INCDIR="g++-v11"
CTARGET="x86_64-pc-linux-gnu"
GCC_SPECS=""
MULTIOSDIRS="../lib64:../lib32"
|
and the only difference in the 17.1 box is this:
| Code: |
--- x86_64-pc-linux-gnu-11.2.0 2022-02-18 16:44:54.142666000 +0000
+++ x86_64-pc-linux-gnu-11.2.0_2 2022-02-18 16:45:03.664104000 +0000
@@ -5,4 +5,4 @@
STDCXX_INCDIR="g++-v11"
CTARGET="x86_64-pc-linux-gnu"
GCC_SPECS=""
-MULTIOSDIRS="../lib64:../lib32"
+MULTIOSDIRS="../lib64:../lib"
|
|
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9714
Location: almost Mile High in the USA
|
| Posted: Fri Feb 18, 2022 4:47 pm Post subject: |
|
|
Well, my old 17.0 profile box seems to work with this, so I suspect this appears to be an artifact of an upgrade to 17.1 that wasn't fully completed I think. Haven't seen this issue on either my 17.0 or 17.1 boxes, though I hope I won't see this issue when I finally upgrade my (last?) 17.0 box...
Question is...what needs to be rebuilt. Was gcc11.2 rebuilt after finally changing the profile to 17.1?
BTW, since gcc9 is no longer latest, the upgrade commands from 17.0 and 17.1 are no longer up to date? ugh :( I really need to do this before the upgrade becomes obsolete....
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
saperski
n00b
Joined: 15 Feb 2022
Posts: 9
|
| Posted: Fri Feb 18, 2022 4:58 pm Post subject: |
|
|
No, the "broken" machine is still at 17.0, but it has been upgraded from 13.0 from many years ago. But I have managed to emerge -ev @world successfully there, except for dev-perl/DBD-mysql which I started to investigate. The compiler and binutils have been rebuilt many times after that in a hope to resolve this.
I am using a freshly installed 17.1 for comparison here (the "good" machine) |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9714
Location: almost Mile High in the USA
|
| Posted: Fri Feb 18, 2022 5:25 pm Post subject: |
|
|
I set my 17.0 box to use gcc11 and binutils2.37p1 and your testcase still works fine.
Diffing your linker.1 output with mine doesn't show much...except that my machine didn't even go through the search path - it found libstdc++.so.6 in one shot without searching.
Small excerpt of the diff:
| diff eccerr0r_linker_out saperski_linker_out wrote: | | Code: | -attempt to open /usr/lib/llvm/8/lib64/libresolv.so.2 failed
-attempt to open /usr/lib/llvm/7/lib32/libresolv.so.2 failed
-attempt to open /usr/lib/llvm/7/lib64/libresolv.so.2 failed
+attempt to open /usr/x86_64-pc-linux-gnu/lib64/libresolv.so.2 failed
+attempt to open /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p164/libresolv.so.2 failed
+attempt to open /usr/local/lib64/libresolv.so.2 failed
found libresolv.so.2 at /lib64/libresolv.so.2
+libpthread.so.0 needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libmysqlclient.so
+attempt to open /usr/x86_64-pc-linux-gnu/lib64/libpthread.so.0 failed
+attempt to open /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p164/libpthread.so.0 failed
+attempt to open /usr/local/lib64/libpthread.so.0 failed
+found libpthread.so.0 at /lib64/libpthread.so.0
libstdc++.so.6 needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libmysqlclient.so
-found libstdc++.so.6 at /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so.6
+attempt to open /usr/x86_64-pc-linux-gnu/lib64/libstdc++.so.6 failed
+attempt to open /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p164/libstdc++.so.6 failed
+attempt to open /usr/local/lib64/libstdc++.so.6 failed
+attempt to open /lib64/libstdc++.so.6 failed
+attempt to open /usr/lib64/libstdc++.so.6 failed
+attempt to open /usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6 failed
+attempt to open /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1/libstdc++.so.6 failed
+attempt to open /usr/local/lib/libstdc++.so.6 failed
+attempt to open /lib/libstdc++.so.6 failed
+attempt to open /usr/lib/libstdc++.so.6 failed
+attempt to open /usr/x86_64-pc-linux-gnu/lib64/libstdc++.so.6 failed
+attempt to open /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p164/libstdc++.so.6 failed
+attempt to open /usr/local/lib64/libstdc++.so.6 failed
+attempt to open /lib64/libstdc++.so.6 failed
+attempt to open /usr/lib64/libstdc++.so.6 failed
+attempt to open /usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6 failed
+attempt to open /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1/libstdc++.so.6 failed
+attempt to open /usr/local/lib/libstdc++.so.6 failed
+attempt to open /lib/libstdc++.so.6 failed
+attempt to open /usr/lib/libstdc++.so.6 failed
libgcc_s.so.1 needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libmysqlclient.so
|
|
(- means mine said it, + means yours said it, (blank) means both of our boxes said it)
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
