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) Reproducible: Always
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.
