Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 550432 - revdep-rebuild: support gcc std::__cxx11 symbol transition
Summary: revdep-rebuild: support gcc std::__cxx11 symbol transition
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal enhancement with 3 votes (vote)
Assignee: Portage Tools Team
URL:
Whiteboard:
Keywords:
: 568614 (view as bug list)
Depends on:
Blocks: gcc-5 c++11-abi 547788
  Show dependency tree
 
Reported: 2015-05-26 05:31 UTC by Jonathan Adamczewski
Modified: 2017-10-04 09:43 UTC (History)
8 users (show)

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


Attachments
Simplistic gcc-5 upgrade support for revdep-rebuild (revdep-rebuild-upgrade-cxx11.diff,2.41 KB, patch)
2015-05-26 05:43 UTC, Jonathan Adamczewski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Adamczewski 2015-05-26 05:31:34 UTC
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
Comment 1 Jonathan Adamczewski 2015-05-26 05:43:10 UTC
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.
Comment 2 Ryan Hill (RETIRED) gentoo-dev 2015-05-26 06:04:11 UTC
> - 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.
Comment 3 Brian Dolbec gentoo-dev 2015-05-26 07:38:07 UTC
cc'ing tools-portage for the revdep-rebuild enhancement.  It looks simple enough, but will require porting to the newer python version.
Comment 4 SpanKY gentoo-dev 2015-12-19 21:05:57 UTC
*** Bug 568614 has been marked as a duplicate of this bug. ***
Comment 5 SpanKY gentoo-dev 2015-12-19 21:06:38 UTC
edge case: some packages only provide static libs (like libplatform), but revdep rebuild does not detect that currently
Comment 6 Oleg 2016-11-29 06:34:15 UTC
(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.
Comment 7 Andreas K. Hüttel gentoo-dev 2017-10-04 09:43:20 UTC
This bug is pretty much obsolete since the transition is now behind us.