| Summary: | sys-devel/gcc[vtv]: Build failure with sys-devel/slibtool | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | orbea <orbea> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | herrtimson, sam |
| Priority: | Normal | Keywords: | PATCH, UPSTREAM |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://gcc.gnu.org/PR99172 | ||
| See Also: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 765709 | ||
| Attachments: |
9.3.0-r2 build log
10.2.0-r5 build log Build without 22_all_libstdcxx-no-vtv.patch |
||
Created attachment 684924 [details]
10.2.0-r5 build log
The problem is in the libstdc++.la make target in libstdc++-v3/src and GNU libtool seems to work by silently removing -lvtv. Before digging further I can suggest a few things to try: 1. Does USE=-vtv work for you as a workaround? 2. Does dropping gentoo-specific patch from the patchset https://gitweb.gentoo.org/proj/gcc-patches.git/tree/10.2.0/gentoo/22_all_libstdcxx-no-vtv.patch make it better? It might have broken -lvtv discovery. Created attachment 685128 [details]
Build without 22_all_libstdcxx-no-vtv.patch
> Does USE=-vtv work for you as a workaround? Yes, the build finishes without errors when using USE=-vtv. > Does dropping gentoo-specific patch from the patchset https://gitweb.gentoo.org/proj/gcc-patches.git/tree/10.2.0/gentoo/22_all_libstdcxx-no-vtv.patch make it better? Seems not, I attached a second log, but it seems to fail the same way. Aha, that's useful. My suspiction is missing build-time dependency of libstdc++ on vtv. The path to inplace vtv is passed, but it does not exist: ``` # rdlibtool --tag CXX --mode=link /var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc/xgcc -shared-libgcc -B/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc -nostdinc++ -L/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fno-checking -Wl,-O1 -Wl,-z,relro -Wl,--gc-sections -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -fvtable-verify=std -Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:28:0 -Wl,--version-script=libstdc++-symbols.ver -lm -rpath /usr/lib/../lib64 compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo compatibility-c++0x.lo compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la ../src/c++17/libc++17convenience.la rdlibtool: link: ar crs .libs/libstdc++.a .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o rdlibtool: link: /var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc/xgcc .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive -Wl,--whole-archive ../src/c++98/.libs/libc++98convenience.a -Wl,--no-whole-archive -Wl,--whole-archive ../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive -Wl,--whole-archive ../src/c++17/.libs/libc++17convenience.a -Wl,--no-whole-archive -shared-libgcc -B/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc -nostdinc++ -L/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fno-checking -Wl,-O1 -Wl,-z,relro -Wl,--gc-sections -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -fvtable-verify=std -Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -Wl,--version-script=libstdc++-symbols.ver -lm -L/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-pc-linux-gnu/libstdc++-v3/../libvtv/.libs -shared -fPIC -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.28 /usr/x86_64-pc-linux-gnu/bin/ld: cannot find -lvtv collect2: error: ld returned 1 exit status rdlibtool: exec error upon slbt_exec_link_create_library(), line 1446: (see child process error messages). rdlibtool: < returned to > slbt_exec_link(), line 1836. ``` ``` # ls /var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-pc-linux-gnu/libstdc++-v3/.. 32 libgcc libstdc++-v3 ``` -lvtv comes from -fvtable-verify=std cflag (not supported and thus silenty filtered out by libtool) from a gcc spec file:
gcc/gcc.c-#define VTABLE_VERIFICATION_SPEC "\
gcc/gcc.c:%{!nostdlib:%{!r:%{fvtable-verify=std: -lvtv -u_vtable_map_vars_start -u_vtable_map_vars_end}\
gcc/gcc.c: %{fvtable-verify=preinit: -lvtv -u_vtable_map_vars_start -u_vtable_map_vars_end}}}"
The complication is that libvtv itself needs libstdc++ flags:
gcc/libvtv $ fgrep -R STDCXX .
./configure.ac:GCC_LIBSTDCXX_RAW_CXX_FLAGS
./Makefile.am:AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
Final vtv library avoid direct dependency on vtv using weak symbols from libstdc++ like insert_only_hash_map<> methods. libstdc++ does the same for vtv symbols.
Library dependency is set in gcc/Makefile.def (propagated to Makefile.in):
$ egrep 'stdc\+\+|vtv' Makefile.def
dependencies = { module=configure-target-libvtv; on=all-target-libstdc++-v3; };
dependencies = { module=install-target-libvtv; on=install-target-libstdc++-v3; };
dependencies = { module=install-target-libvtv; on=install-target-libgcc; };
dependencies = { module=install-target-libstdc++-v3; on=install-target-libgcc; };
I don't think there is a simple one-liner solution. I suggest you to follow up with upstream and decide on the slibtool support in gcc and maybe sorting out vtv flags for libstdc++-v3. Avoidinig -lvtv at least for libstdc++ itself would probably make sense.
Upstream issue. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 From the upstream gcc issue.
> I don't know why you want to use --enable-vtable-verify but it's not really maintained as far as I can see.
Maybe it should not be default in gentoo?
Yes, disabling vtv is reasonable. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63c16d8b5e71b5f8e6185965062cf9c836800c29 commit 63c16d8b5e71b5f8e6185965062cf9c836800c29 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2021-02-22 21:57:22 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-02-22 22:00:10 +0000 eclass/toolchain.eclass: disable USE=vtv on gcc-10 and above USE=vtv has a few problems: - it's build system has a few quirks: bug #767706, bug #582524 - it's developed in gcc for a while Bug: https://bugs.gentoo.org/582524 Bug: https://bugs.gentoo.org/767706 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/toolchain.eclass | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) This has been fixed upstream. https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=c2be82058fb40f3ae891c68d185ff53e07f14f45 Also as discussed in the upstream issue it seems --enable-vtable-verify is still maintained upstream. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=ff3a446afb9e0abb87869e85826454e85ef398c3 commit ff3a446afb9e0abb87869e85826454e85ef398c3 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2021-03-15 22:55:21 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-03-15 22:57:07 +0000 10.2.0: fix vtv build on slibtool Reported-by: orbea@riseup.net Bug: https://gcc.gnu.org/PR99172 Bug: https://bugs.gentoo.org/767706 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> 10.2.0/gentoo/43_all_vtv-slibtool.patch | 62 +++++++++++++++++++++++++++++++++ 10.2.0/gentoo/README.history | 1 + 2 files changed, 63 insertions(+) The patch queued for next gcc-10.2.0 patchset.
Meanwhile you can drop it into
/etc/portage/patches/sys-devel/gcc:10/
or similar.
Should be released with gcc-10.3 |
Created attachment 684921 [details] 9.3.0-r2 build log When building gcc-9.3.0-r2 or gcc-10.2.0-r5 with slibtool it fails. /usr/x86_64-pc-linux-gnu/bin/ld: cannot find -lvtv Note that gcc drops the value of MAKEFLAGS during the build so to use slibtool the MAKE variable must be set instead. MAKE='make LIBTOOL=rdlibtool' emerge -av sys-devel/gcc