On 12/1/15 6:25 AM, Michał Górny wrote: > > Dnia 30 listopada 2015 12:17:32 CET, "Anthony G. Basile" > <bluen...@gentoo.org> napisał(a): >> >> different direction: what about building with >> rpath=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/ and then making sure that >> portage respects that library file during any --depclean or >> @preserved-rebuild? i'm not sure how we'd >> inject|||LDFLAGS=-Wl,-rpath=... consistantly and sanely into all c++ >> builds. >> >> this would solve all problems i can see: 1) gcc-config reshuffles >> /etc/ld.so.conf.d/05gcc-<tuple>.conf but rpath takes presidence, 2) the >> correct library symbols are guaranteed to be there in both exe and lib. >> >> 3) it pro-actively guards against abi mismatches when switching gcc >> even >> for other languages like fortran, java, obj-c.| > I'm afraid any of those problems are really affecting us here. GCC maintains > backwards ABI compatibility in the library, so applications will continue to > work as long as runtime libstdc++ isn't older than build time. > > Currently, we always force newest installed libstdc++ at runtime, and use the > version matching GCC version at build time, so that works. > > So the best thing your solution could give us is loading the wrong version of > libstdc++ when you link to a library built against older one. Yeah there are two problems going on here and the libsigc++-2.6 is the c++98 <=> 11 problem. So on that bug we're talking about selectively adding -std=c++11 (or possibly gnu++11) to packages. This may get messy. I'm wondering if it isn't possible to just globally add CXXFLAGS+="-std=c++11". This should work because anything written with c++98 will compile under c++11 (although not vice versa) although I don't know how we'd migrate existing systems.
-- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
