Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 767706 - sys-devel/gcc[vtv]: Build failure with sys-devel/slibtool
Summary: sys-devel/gcc[vtv]: Build failure with sys-devel/slibtool
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
Depends on:
Blocks: slibtool
  Show dependency tree
Reported: 2021-01-27 20:50 UTC by orbea
Modified: 2021-04-29 07:10 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

9.3.0-r2 build log (build-gcc-9.3.0-r2.log.xz,81.82 KB, application/x-xz)
2021-01-27 20:50 UTC, orbea
10.2.0-r5 build log (build-gcc-10.2.0-r5.log.xz,84.19 KB, application/x-xz)
2021-01-27 20:50 UTC, orbea
Build without 22_all_libstdcxx-no-vtv.patch (build-gcc-10.2.0-r5.2.log.xz,83.88 KB, application/x-xz)
2021-01-29 16:27 UTC, orbea

Note You need to log in before you can comment on or make changes to this bug.
Description orbea 2021-01-27 20:50:09 UTC
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
Comment 1 orbea 2021-01-27 20:50:33 UTC
Created attachment 684924 [details]
10.2.0-r5 build log
Comment 2 orbea 2021-01-27 22:41:57 UTC
The problem is in the make target in libstdc++-v3/src and GNU libtool seems to work by silently removing -lvtv.
Comment 3 Sergei Trofimovich (RETIRED) gentoo-dev 2021-01-29 06:57:08 UTC
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 make it better? It might have broken -lvtv discovery.
Comment 4 orbea 2021-01-29 16:27:47 UTC
Created attachment 685128 [details]
Build without 22_all_libstdcxx-no-vtv.patch
Comment 5 orbea 2021-01-29 16:30:16 UTC
> 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 make it better?

Seems not, I attached a second log, but it seems to fail the same way.
Comment 6 Sergei Trofimovich (RETIRED) gentoo-dev 2021-01-30 10:10:39 UTC
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 -o -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++/ ../src/c++98/ ../src/c++11/ ../src/c++17/

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 -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, -o .libs/
/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
Comment 7 Sergei Trofimovich (RETIRED) gentoo-dev 2021-01-30 11:34:43 UTC
-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 .

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

$ 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.
Comment 8 orbea 2021-02-19 20:53:33 UTC
Upstream issue.
Comment 9 orbea 2021-02-22 16:19:23 UTC
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?
Comment 10 Sergei Trofimovich (RETIRED) gentoo-dev 2021-02-22 21:50:25 UTC
Yes, disabling vtv is reasonable.
Comment 11 Larry the Git Cow gentoo-dev 2021-02-22 22:00:13 UTC
The bug has been referenced in the following commit(s):

commit 63c16d8b5e71b5f8e6185965062cf9c836800c29
Author:     Sergei Trofimovich <>
AuthorDate: 2021-02-22 21:57:22 +0000
Commit:     Sergei Trofimovich <>
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
    Signed-off-by: Sergei Trofimovich <>

 eclass/toolchain.eclass | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
Comment 12 orbea 2021-03-15 22:05:50 UTC
This has been fixed upstream.;h=c2be82058fb40f3ae891c68d185ff53e07f14f45

Also as discussed in the upstream issue it seems --enable-vtable-verify is still maintained upstream.
Comment 13 Larry the Git Cow gentoo-dev 2021-03-15 22:57:58 UTC
The bug has been referenced in the following commit(s):

commit ff3a446afb9e0abb87869e85826454e85ef398c3
Author:     Sergei Trofimovich <>
AuthorDate: 2021-03-15 22:55:21 +0000
Commit:     Sergei Trofimovich <>
CommitDate: 2021-03-15 22:57:07 +0000

    10.2.0: fix vtv build on slibtool
    Signed-off-by: Sergei Trofimovich <>

 10.2.0/gentoo/43_all_vtv-slibtool.patch | 62 +++++++++++++++++++++++++++++++++
 10.2.0/gentoo/README.history            |  1 +
 2 files changed, 63 insertions(+)
Comment 14 Sergei Trofimovich (RETIRED) gentoo-dev 2021-03-15 22:59:03 UTC
The patch queued for next gcc-10.2.0 patchset.

Meanwhile you can drop it into
or similar.
Comment 15 Sergei Trofimovich (RETIRED) gentoo-dev 2021-04-29 07:10:52 UTC
Should be released with gcc-10.3