A common source of compile failures after upgrading to gcc-5.1.0 is due to std::string changing from std::basic_string to std::__cxx11::basic_string.
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html states that the standard library includes both implementations, but any library that exports symbols whose signatures include std::string will - by default - change from exporting the former to exporting the latter when rebuilt.
When merging packages that include calls to functions with std::string in their signature, these will fail at link time if the functions are provided by libraries that have not been rebuilt with gcc-5 as they will expect to find the __cxx11 variant of the symbol.
Libraries that export symbols with std::string need to be rebuilt to avoid this class of build failures.
I can see a few possible ways of handling this breakage:
- Directly rebuild packages that require it. Something like revdep-rebuild, but searching for symbols (defined and undefined) that include std::basic_string. (I have a basic modification to revdep-rebuild that attempts to do this - I'll post a patch...)
- Sufficient extra smarts in portage to track ABI changes in a way that won't require rebuilds to everything built with an older gcc version, or everything linking to libstdc++.so - a significantly smaller subset of packages are broken
- Manually rebuild libraries on demand as other packages fail to build. This is tedious, and breakage is likely when a library is rebuilt but its dependent packages are not.
- Just rebuild everything on the system. I have 1500 packages installed on my primary machine - this is a highly unappealing option as only a small number of those packages require a rebuild.
- Force all newly merged packages to use the older ABI (via something like -D_GLIBCXX_USE_CXX11_ABI=0 in CXXFLAGS). It seems possible that this might actually work - but is likely to cause conflicts and greater difficulties in the longer term. [this isn't a serious suggestion]
(std::list has been similarly changed, but I've not observed problems caused by that type being used in a public interface)
Created attachment 403986 [details, diff]
Simplistic gcc-5 upgrade support for revdep-rebuild
This adds an option -u that will scan each target found by revdep-rebuild and very naively look for references to std::basic_stream in the output of nm -C.
It will return some results that need not be rebuilt e.g. sys-devel/gcc and cross-compilers. These could be filtered with files in /etc/revdep-rebuild similar to other special cases.
Binary files referencing the older symbol will be wrongly reported as requiring a rebuild.
A package that legitimately uses _GLIBCXX_USE_CXX11_ABI=0 will be wrongly reported as requiring a rebuild.
> - Just rebuild everything on the system. I have 1500 packages installed on my
> primary machine - this is a highly unappealing option as only a small number
> of those packages require a rebuild.
This is pretty much mandatory after a major version bump of gcc anyways, and especially so with this version. I'm sure we'll be putting out a news item when we unmask it recommending emerge -e @world.
I'll leave this open as an enhancement request in case anyone wants to look into your changes for revdep-rebuild.
cc'ing tools-portage for the revdep-rebuild enhancement. It looks simple enough, but will require porting to the newer python version.
*** Bug 568614 has been marked as a duplicate of this bug. ***
edge case: some packages only provide static libs (like libplatform), but revdep rebuild does not detect that currently
(In reply to Jonathan Adamczewski from comment #1)
> Created attachment 403986 [details, diff] [details, diff]
> Simplistic gcc-5 upgrade support for revdep-rebuild
> This adds an option -u that will scan each target found by revdep-rebuild
> and very naively look for references to std::basic_stream in the output of
> nm -C.
> It will return some results that need not be rebuilt e.g. sys-devel/gcc and
> cross-compilers. These could be filtered with files in /etc/revdep-rebuild
> similar to other special cases.
> Binary files referencing the older symbol will be wrongly reported as
> requiring a rebuild.
> A package that legitimately uses _GLIBCXX_USE_CXX11_ABI=0 will be wrongly
> reported as requiring a rebuild.
i adapted this to revdep-rebuild.sh from newer 0.3.2 (had to use -z, because -u is already present in 0.3.2), however when update happened in fresh chroot (4.9.3 to 5.3.0), revdep-rebuild.sh unable to find packages with std::basic_string; grep pattern or it doesn't trigger rebuild.
This bug is pretty much obsolete since the transition is now behind us.