| View previous topic :: View next topic |
| Author |
Message |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
 Posted: Thu Apr 29, 2021 11:17 am Post subject: Do not compile gcc-11 w/ -fvisibility-inlines-hidden |
 |
|
Hi,
this is just a heads-up: After emerging gcc-11.1.0 switching to that gcc and re-emerging libtools, I had a lot of trouble. For instance, firefox segfaulted, sddm did not come up. A re-emerge of sddm failed (independent of the gcc version) with | Code: | | /usr/lib64/qt5/bin/lrelease: symbol lookup error: /usr/lib64/libQt5Core.so.5: undefined symbol: _ZNSt15__exception_ptreqERKNS_13exception_ptrES2_, version CXXABI_1.3.3 |
Note that these problems happened before I used the new gcc to compile anything. Moreover, also reverting to my previously used gcc-10.3.0 as the system compiler did not fix anything.
The solution was: Reemerge qtcore with gcc-11.1.0.
My conjecture: independent of the selected gcc, some library of the new gcc-11.1 is used which is not completely ABI compatible.
Last edited by mv on Tue May 04, 2021 2:04 pm; edited 1 time in total |
|
| Back to top |
|
 |
xaviermiller
Bodhisattva
Joined: 23 Jul 2004
Posts: 8708
Location: ~Brussels - Belgique
|
|
| Back to top |
|
|
DaggyStyle
Watchman
Joined: 22 Mar 2006
Posts: 5909
|
| Posted: Thu Apr 29, 2021 11:52 am Post subject: |
|
|
so after gcc upgrade, we should rebuild the entire tree?
_________________
Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein |
|
| Back to top |
|
|
Perfect Gentleman
Veteran
Joined: 18 May 2014
Posts: 1249
|
| Posted: Thu Apr 29, 2021 12:02 pm Post subject: |
|
|
| I've rebuilt @system just in case. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Apr 29, 2021 12:14 pm Post subject: |
|
|
I am not absolutely sure about the cause. Only that I do not see anything else which might have caused it is not a proof that my conjecture is right. It might also have been a side effect of something I currently cannot imagine. IMHO, this is not enough to modify the wiki but enough to give a heads-up. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Apr 29, 2021 4:00 pm Post subject: |
|
|
I verified now on another machine:
was working while emerging gcc in another window. When the emerge was ready, I got for the above command
| Code: | | /usr/lib64/qt5/bin/lrelease: symbol lookup error: /usr/lib64/libQt5Core.so.5: undefined symbol: _ZNSt15__exception_ptreqERKNS_13exception_ptrES2_, version CXXABI_1.3.3 |
even before calling gcc-config for the new compiler.
Edit: The problem happened only on amd64, not on x86. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Thu Apr 29, 2021 5:22 pm Post subject: |
|
|
Big meh if this turns out to be true.
That said:
| Code: | $ emerge --info | head -n1
Portage 3.0.18 (python 3.9.4-final-0, default/linux/amd64/17.1/desktop/plasma, gcc-10.3.0, glibc-2.33, 5.11.13-gentoo x86_64)
$ equery l gcc
[IP-] [ ] sys-devel/gcc-10.3.0:10
[IP-] [ ] sys-devel/gcc-11.1.0:11
$ gcc-config -l
[1] x86_64-pc-linux-gnu-10.3.0 *
[2] x86_64-pc-linux-gnu-11.1.0
$ /usr/lib64/qt5/bin/lrelease -h
Usage:
lrelease [options] -project project-file
...
|
But, isn't this a weird subforum for this thread? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Apr 29, 2021 5:48 pm Post subject: |
|
|
| asturm wrote: | | Big meh if this turns out to be true. |
It might be related that gcc-11.1.0 is the first ebuild which can honour custom-cflags, and perhaps some of my flags change the ABI. I wouldn't have expected anything to happen, anyway, until I switch to the new compiler with gcc.
| Quote: | | But, isn't this a weird subforum for this thread? |
Yes, feel free to move. I found no appropriate forum. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Fri Apr 30, 2021 1:45 am Post subject: |
|
|
| mv wrote: | | Code: | | /usr/lib64/qt5/bin/lrelease: symbol lookup error: /usr/lib64/libQt5Core.so.5: undefined symbol: _ZNSt15__exception_ptreqERKNS_13exception_ptrES2_, version CXXABI_1.3.3 |
|
The symbol is defined in libstdc++, it seems to be part of the implementation of the type std::exception_ptr defined in <exception>. Is it different for GCC 11.1?
| Code: | $ nm -DC libstdc++.so.6 | grep 'operator==.*exception_ptr'
00000000000d0530 T std::__exception_ptr::operator==(std::__exception_ptr::exception_ptr const&, std::__exception_ptr::exception_ptr const&)@@CXXABI_1.3.3
$ nm -D libstdc++.so.6 | grep d0530
00000000000d0530 T _ZNSt15__exception_ptreqERKNS_13exception_ptrES2_@@CXXABI_1.3.3 |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Apr 30, 2021 6:34 am Post subject: |
|
|
| GDH-gentoo wrote: | | The symbol is defined in libstdc++, it seems to be part of the implementation of the type std::exception_ptr defined in <exception>. Is it different for GCC 11.1? |
At least, in my case it is different:
| Code: | % nm -DC /usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/libstdc++.so.6 | grep 'operator==.*exception_ptr'
00000000000d8400 T std::__exception_ptr::operator==(std::__exception_ptr::exception_ptr const&, std::__exception_ptr::exception_ptr const&)@@CXXABI_1.3.3
% nm -DC /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/libstdc++.so.6 | grep 'operator==.*exception_ptr'
% # (no output)
% nm -DC /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/libstdc++.so.6 | grep 'exception_ptr'
00000000000d59b0 T std::__exception_ptr::exception_ptr::__cxa_exception_type() const@@CXXABI_1.3.3
00000000000d5990 T std::__exception_ptr::exception_ptr::operator void (std::__exception_ptr::exception_ptr::*)()() const@@CXXABI_1.3.3
00000000000d5980 T std::__exception_ptr::exception_ptr::operator!() const@@CXXABI_1.3.3
00000000000d58a0 T std::__exception_ptr::exception_ptr::_M_release()@@CXXABI_1.3.13
00000000000d5830 W std::__exception_ptr::exception_ptr::swap(std::__exception_ptr::exception_ptr&)@@CXXABI_1.3.3
00000000000d5880 T std::__exception_ptr::exception_ptr::_M_addref()@@CXXABI_1.3.13
00000000000d5870 T std::__exception_ptr::exception_ptr::exception_ptr(void (std::__exception_ptr::exception_ptr::*)())@@CXXABI_1.3.3
00000000000d5850 T std::__exception_ptr::exception_ptr::exception_ptr(void*)@@CXXABI_1.3.11
00000000000d5810 W std::__exception_ptr::exception_ptr::exception_ptr(std::__exception_ptr::exception_ptr const&)@@CXXABI_1.3.3
00000000000d5800 W std::__exception_ptr::exception_ptr::exception_ptr()@@CXXABI_1.3.3
00000000000d5870 T std::__exception_ptr::exception_ptr::exception_ptr(void (std::__exception_ptr::exception_ptr::*)())@@CXXABI_1.3.3
00000000000d5810 W std::__exception_ptr::exception_ptr::exception_ptr(std::__exception_ptr::exception_ptr const&)@@CXXABI_1.3.3
00000000000d5800 W std::__exception_ptr::exception_ptr::exception_ptr()@@CXXABI_1.3.3
00000000000d58f0 W std::__exception_ptr::exception_ptr::~exception_ptr()@@CXXABI_1.3.3
00000000000d58f0 W std::__exception_ptr::exception_ptr::~exception_ptr()@@CXXABI_1.3.3
00000000000d5910 W std::__exception_ptr::exception_ptr::operator=(std::__exception_ptr::exception_ptr const&)@@CXXABI_1.3.3
00000000000d5a30 T std::rethrow_exception(std::__exception_ptr::exception_ptr)@@CXXABI_1.3.3
00000000000d4aa0 T __cxa_get_exception_ptr@@CXXABI_1.3.1 |
Edit: The definition is conditional in gcc-11.1:
| Code: |
#if __cpp_impl_three_way_comparison >= 201907L \
&& ! defined _GLIBCXX_EH_PTR_RELOPS_COMPAT
friend bool
operator==(const exception_ptr&, const exception_ptr&) noexcept = default;
#else
friend _GLIBCXX_EH_PTR_USED bool
operator==(const exception_ptr& __x, const exception_ptr& __y)
_GLIBCXX_USE_NOEXCEPT
{ return __x._M_exception_object == __y._M_exception_object; }
|
In 10.3.0 there is only the first branch, unconditionally. I assume that in 11.1 the second branch is chosen on my system which has an inline implmentation.
Anyway, what I do not understand is why the 11.1 library is chosen even if 10.3 is selected with gcc-config. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Sat May 01, 2021 3:53 pm Post subject: |
|
|
| mv wrote: | Edit: The definition is conditional in gcc-11.1:
| Code: |
#if __cpp_impl_three_way_comparison >= 201907L \
&& ! defined _GLIBCXX_EH_PTR_RELOPS_COMPAT
friend bool
operator==(const exception_ptr&, const exception_ptr&) noexcept = default;
#else
friend _GLIBCXX_EH_PTR_USED bool
operator==(const exception_ptr& __x, const exception_ptr& __y)
_GLIBCXX_USE_NOEXCEPT
{ return __x._M_exception_object == __y._M_exception_object; } |
In 10.3.0 there is only the first branch, unconditionally. I assume that in 11.1 the second branch is chosen on my system which has an inline implmentation. |
That's libstdc++-v3/libsupc++/exception_ptr.h, right?
Interesting, but i don´t understand what happened. If I understand correctly, only the first branch could result in no symbol emitted for std::__exception_ptr::operator==(). File libstdc++-v3/libsupc++/eh_ptr.cc, which is used to generate the libstdc++ library, contains:
| Code: | #include <bits/c++config.h>
// ...
#if ! _GLIBCXX_INLINE_VERSION
// This macro causes some inline functions in exception_ptr to be marked
// as "used" so that definitions will be emitted in this translation unit.
// We need this because those functions were not inline in previous releases.
#define _GLIBCXX_EH_PTR_RELOPS_COMPAT
#endif
// ...
#include <bits/exception_ptr.h> |
So, the first branch in exception_ptr.h would be skipped if the value that _GLIBCXX_INLINE_VERSION expands to is 0. For me, <bits/c++config.h> contains:
| Code: | | #define _GLIBCXX_INLINE_VERSION 0 |
The equivalent file for 11.1.0 should be installed in /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/x86_64-pc-linux-gnu/bits, if I'm not mistaken. Does the value change?
| mv wrote: | | Anyway, what I do not understand is why the 11.1 library is chosen even if 10.3 is selected with gcc-config. |
Neither do I. The file dropped by gcc-config in /etc/ld.so.conf.d should direct the dynamic linker to search for libstdc++ in /usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat May 01, 2021 5:43 pm Post subject: |
|
|
| GDH-gentoo wrote: | | That's libstdc++-v3/libsupc++/exception_ptr.h, right? |
No, it is bits/exception_ptr.h.
| Quote: | | only the first branch could result in no symbol emitted for std::__exception_ptr::operator==(). |
No; the second branch contains only inline functions, so it will not omit any symbol. The first branch requires that some .cc file omitted a symbol. I guess that's what happened somewhere else if that branch is reached.
| Quote: | | // We need this because those functions were not inline in previous releases. |
So this seems to be an intended ABI breakage: If you define the *COMPAT symbol, you get an ABI compatible library, otherwise (probably the default or at least the codepath chosen on my systems for whatever reason) not. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Sat May 01, 2021 6:53 pm Post subject: |
|
|
| mv wrote: | | GDH-gentoo wrote: | | That's libstdc++-v3/libsupc++/exception_ptr.h, right? |
No, it is bits/exception_ptr.h. |
OK, it's the same file. libstdc++-v3/libsupc++/exception_ptr.h gets installed to /usr/lib/gcc/$CHOST/GCC version/include/g++*/bits.
| mv wrote: | | Quote: | | only the first branch could result in no symbol emitted for std::__exception_ptr::operator==(). |
No; the second branch contains only inline functions, so it will not omit any symbol. |
If I undertand correctly, _GLIBCXX_EH_PTR_USED expands to __attribute__((__used__)), and that GCC incantation should result in emitting the symbol even if the function is inline. I believe that's what the "[...] causes some inline functions in exception_ptr to be marked as "used" so that definitions will be emitted [...]" part of the comment in eh_ptr.cc means.
| Quote: | | The first branch requires that some .cc file omitted a symbol |
Why? If I'm not mistaken, the first branch is already a definition, an explicitly-defaulted definition of std::__exception_ptr::operator==(). Which also makes it implicitly inline. And I believe that compilers might not necessarily generate code for a function call (and emit a symbol) when functions that are explicitly defaulted in their first declaration would be called.
| mv wrote: | | If you define the *COMPAT symbol, you get an ABI compatible library, [...] |
IIUC, the *COMPAT macro will be defined if the value that _GLIBCXX_INLINE_VERSION (defined in <bits/c++config.h>) expands to is 0. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun May 02, 2021 8:00 am Post subject: |
|
|
| GDH-gentoo wrote: | | If I undertand correctly, _GLIBCXX_EH_PTR_USED expands to __attribute__((__used__)) |
Oh, I missed that.
| Quote: | | the first branch is already a definition |
Indeed, you are right, I missed the = default.
| Quote: | | IIUC, the *COMPAT macro will be defined if the value that _GLIBCXX_INLINE_VERSION (defined in <bits/c++config.h>) expands to is 0. |
The installed headers do not define the *COMPAT macro (though _GLIBCXX_INLINE_VERSION is 0). Maybe for some reason the _GLIBCXX_INLINE_VERSION is not 0 when the library is compiled. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun May 02, 2021 8:02 am Post subject: |
|
|
| I also had to recompile llvm and lld. I will now recompile my whole system to be sure. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun May 02, 2021 5:07 pm Post subject: |
|
|
Hmm. Recompile of quite a lot of packages fails. Linking continuously fails with the same error: The symbol
| Quote: | | std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() |
is missing. Sample of failing package: app-crypt/gpgme (all versions). |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Sun May 02, 2021 8:01 pm Post subject: |
|
|
| mv wrote: | Recompile of quite a lot of packages fails. Linking continuously fails with the same error: The symbol
| Quote: | | std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() |
is missing. |
Runtime failure? Missing symbol in libstdc++ again?
| Code: | $ nm -DC libstdc++.so.6 | grep 'string<char.*M_dispose'
0000000000170770 W std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()@@GLIBCXX_3.4.21 |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun May 02, 2021 8:07 pm Post subject: |
|
|
| GDH-gentoo wrote: | | mv wrote: | Recompile of quite a lot of packages fails. Linking continuously fails with the same error: The symbol
| Quote: | | std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() |
is missing. |
Runtime failure? |
So far only a link-time failure.
| Quote: | Missing symbol in libstdc++ again?
| Code: | $ nm -DC libstdc++.so.6 | grep 'string<char.*M_dispose'
0000000000170770 W std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()@@GLIBCXX_3.4.21 |
|
No output here. Also in the header files it is this time clearly inlined; I could not see any constant involved which could change this. (Unless I missed again something...)
What worries me is that e.g. in gpgme it occurs in the main method - the corresponding .o file was just compiled with gcc-11.1, so it should have been inlined... Perhaps some implicit include which should have happened is missing. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Mon May 03, 2021 9:55 pm Post subject: |
|
|
| mv wrote: | | Quote: | Missing symbol in libstdc++ again?
| Code: | $ nm -DC libstdc++.so.6 | grep 'string<char.*M_dispose'
0000000000170770 W std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()@@GLIBCXX_3.4.21 |
|
No output here. Also in the header files it is this time clearly inlined; I could not see any constant involved which could change this. |
Strange again. File libstdc++-v3/src/c++11/string-inst.cc, which is also used to build libstdc++, contains an explicit instantiation definition for this particular specialization of std::basic_string<>.
| Code: | #include <string>
// Instantiation configuration.
#ifndef C
# define C char
#endif
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
// ...
template class basic_string<C>;
// ...
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace |
So I'd excpect a symbol for its _M_dispose() member function to be emitted. Then <bits/basic_string.tcc>, which is included in every source file that includes <string>, contains:
| Code: | namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
// ...
// Inhibit implicit instantiations for required instantiations,
// which are defined via explicit instantiations elsewhere.
#if _GLIBCXX_EXTERN_TEMPLATE
// The explicit instantiation definitions in src/c++11/string-inst.cc and
// src/c++17/string-inst.cc only instantiate the members required for C++17
// and earlier standards (so not C++20's starts_with and ends_with).
// Suppress the explicit instantiation declarations for C++20, so C++20
// code will implicitly instantiate std::string and std::wstring as needed.
# if __cplusplus <= 201703L && _GLIBCXX_EXTERN_TEMPLATE > 0
extern template class basic_string<char>;
# elif ! _GLIBCXX_USE_CXX11_ABI
// ...
# endif
// ...
#endif // _GLIBCXX_EXTERN_TEMPLATE
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace std |
I'm not entirely sure what explicit instantiation declarations (i.e. those with extern template) are supposed to do, but that might direct the compiler to link to the instantiated member functions in libstdc++.
Also, <bits/c++config.h> contains in my case:
| Code: | // Macro for extern template, ie controlling template linkage via use
// of extern keyword on template declaration. As documented in the g++
// manual, it inhibits all implicit instantiations and is used
// throughout the library to avoid multiple weak definitions for
// required types that are already explicitly instantiated in the
// library binary. This substantially reduces the binary size of
// resulting executables.
// ...
# define _GLIBCXX_EXTERN_TEMPLATE 1 |
|
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30909
Location: here
|
| Posted: Tue May 04, 2021 9:19 am Post subject: |
|
|
Moved from Kernel & Hardware to Portage & Programming.
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue May 04, 2021 2:01 pm Post subject: |
|
|
After O(log 50) compilations of gcc for a binary search on my settings (*FLAGS, USE-flags, ccache, ...), I finally found the culprit:
-fvisibility-inlines-hidden
Once that I know it, it is perhaps not too surprising, but it was not my first candidate because:- I wouldn't have expected that it overrides __attribute__((__used__))
- If it is indeed that aggressive that it even overrides __attribute__((__used__)), I would have expected to get a practically useless library and not one in which only 2 exotic symbols are missing.
In fact, I recompiled world with the (broken) gcc-11, and all packages failing due to the problem were- gpgme
- advancemame
- ipe
The other package failures were unrelated and simply fixed by trivial patches. No runtime problems. |
|
| Back to top |
|
|
Perfect Gentleman
Veteran
Joined: 18 May 2014
Posts: 1249
|
| Posted: Tue May 04, 2021 3:21 pm Post subject: |
|
|
| building packages with -fvisibility-inlines-hidden is very bad idea. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue May 04, 2021 5:04 pm Post subject: |
|
|
| Perfect Gentleman wrote: | | building packages with -fvisibility-inlines-hidden is very bad idea. |
So far, I had to filter it only for 3 packages: ginac, octave, wxGTK. And now new of course >=gcc-11. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Tue May 04, 2021 6:13 pm Post subject: |
|
|
| Quote: | | Lastly, there's one other new command line switch: -fvisibility-inlines-hidden. This causes all inlined class member functions to have hidden visibility, causing significant export symbol table size & binary size reductions though not as much as using -fvisibility=hidden. However, -fvisibility-inlines-hidden can be used with no source alterations, unless you need to override it for inlines where address identity is important either for the function itself or any function local static data. |
Hmm
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
geki
Advocate
Joined: 13 May 2004
Posts: 2387
Location: Germania
|
| Posted: Tue May 04, 2021 7:19 pm Post subject: |
|
|
| Code: | ana ~ # grep CXXFLAGS /etc/portage/make.conf
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden" |
Re-emerged toolchain, world and kernel with gcc-11.1. Rebooted and works.  
Though, this is a headless box. 
A well, surely I did not enable custom-cflags for glibc/gcc. Then you are in for a good ride, indeed. ha ha.
_________________
hear hear
Last edited by geki on Tue May 04, 2021 7:57 pm; edited 3 times in total |
|
| Back to top |
|
|
|
Portage & Programming
