Re: [gentoo-dev] How to support C++11 in libraries?
Dnia 2013-12-19, o godz. 00:56:31 C. Bergström cbergst...@pathscale.com napisał(a): On 12/19/13 12:47 AM, Kent Fredric wrote: On 19 December 2013 06:33, Jan Kundrát j...@gentoo.org wrote: I'm worried by the cost of such a policy, though, because we would suddenly have to patch some unknown amount of software Given the nature that changing that CXX Flag globally for all users could cause many packages to spontaneously fail to build, wouldn't that imply that changing that flag would essentially be de-stabilizing the whole tree, and a package being (arch) would no longer be an indication of sane, tested behaviour? This is really the perk of the USE driven process, the granular piecemeal approach that does only as much as necessary, without changing things that are already stable. In practice wouldn't that mean you'd have to add c++11 USE flag to every C++11 application and lib? No. Only the libs that change their ABI in C++11. Best case both build and you end up with a linker problem (can be worked around with compiler patches) /usr/lib64/libboost.so /usr/lib64-c++11/libboost.so What's wrong with this solution: 1. distro-specific compiler patching is wrong, 2. kinda FHS deviation, at least in spirit of libqual directory. We could go with '-L' but this is very fragile anyway. It's *very easy* for the compiler to link the 'wrong' library due to -L/usr/lib64 being added by some kind of foo-config. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] How to support C++11 in libraries?
On 12/19/13 03:20 PM, Michał Górny wrote: Dnia 2013-12-19, o godz. 00:56:31 C. Bergström cbergst...@pathscale.com napisał(a): On 12/19/13 12:47 AM, Kent Fredric wrote: On 19 December 2013 06:33, Jan Kundrát j...@gentoo.org wrote: I'm worried by the cost of such a policy, though, because we would suddenly have to patch some unknown amount of software Given the nature that changing that CXX Flag globally for all users could cause many packages to spontaneously fail to build, wouldn't that imply that changing that flag would essentially be de-stabilizing the whole tree, and a package being (arch) would no longer be an indication of sane, tested behaviour? This is really the perk of the USE driven process, the granular piecemeal approach that does only as much as necessary, without changing things that are already stable. In practice wouldn't that mean you'd have to add c++11 USE flag to every C++11 application and lib? No. Only the libs that change their ABI in C++11. Best case both build and you end up with a linker problem (can be worked around with compiler patches) /usr/lib64/libboost.so /usr/lib64-c++11/libboost.so What's wrong with this solution: 1. distro-specific compiler patching is wrong, Pragmatically, this needs to be upstream and should have been there already. Get some feedback to see if gcc people are receptive to the idea before testing a gentoo-only patch. If they accept it upstream - backport it. If they tell you f* off - get their feedback on how to deal with it - more below. (this is not a gentoo only problem - this discussion should happen on a more global level...) Unfortunately, it's going to be really hard to tell what will break ABI and what won't. I guess for ABI compatible packages /usr/lib64-c++11/libfoobar.so would be a symlink back to /usr/lib64/libfoobar.so 2. kinda FHS deviation, at least in spirit of libqual directory. We could go with '-L' but this is very fragile anyway. It's *very easy* for the compiler to link the 'wrong' library due to -L/usr/lib64 being added by some kind of foo-config. -L would likely mean you also need -nostdlib to make it work - which is more hacky than the above. pretty please don't do this.. plaassse
Re: [gentoo-dev] How to support C++11 in libraries?
Dnia 2013-12-19, o godz. 15:28:46 C. Bergström cbergst...@pathscale.com napisał(a): On 12/19/13 03:20 PM, Michał Górny wrote: Dnia 2013-12-19, o godz. 00:56:31 C. Bergström cbergst...@pathscale.com napisał(a): On 12/19/13 12:47 AM, Kent Fredric wrote: On 19 December 2013 06:33, Jan Kundrát j...@gentoo.org wrote: I'm worried by the cost of such a policy, though, because we would suddenly have to patch some unknown amount of software Given the nature that changing that CXX Flag globally for all users could cause many packages to spontaneously fail to build, wouldn't that imply that changing that flag would essentially be de-stabilizing the whole tree, and a package being (arch) would no longer be an indication of sane, tested behaviour? This is really the perk of the USE driven process, the granular piecemeal approach that does only as much as necessary, without changing things that are already stable. In practice wouldn't that mean you'd have to add c++11 USE flag to every C++11 application and lib? No. Only the libs that change their ABI in C++11. Best case both build and you end up with a linker problem (can be worked around with compiler patches) /usr/lib64/libboost.so /usr/lib64-c++11/libboost.so What's wrong with this solution: 1. distro-specific compiler patching is wrong, Pragmatically, this needs to be upstream and should have been there already. Get some feedback to see if gcc people are receptive to the idea before testing a gentoo-only patch. If they accept it upstream - backport it. If they tell you f* off - get their feedback on how to deal with it - more below. (this is not a gentoo only problem - this discussion should happen on a more global level...) And how is this an issue to the major distributions? Binary distros can do a simple switch with standard all-package upgrade and forget about it. Like they usually do. Only people who built from sources have to think about it. 2. kinda FHS deviation, at least in spirit of libqual directory. We could go with '-L' but this is very fragile anyway. It's *very easy* for the compiler to link the 'wrong' library due to -L/usr/lib64 being added by some kind of foo-config. -L would likely mean you also need -nostdlib to make it work - which is more hacky than the above. pretty please don't do this.. plaassse What? I have no idea what you're trying to accomplish but this seems out of the scope of the problem. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 02:41:55 CEST, hero...@gentoo.org wrote: I'd like to make an analogy to the version bump of gcc[1]. We (gentoo) decide to support c++11 officially or not. If so, open a tracker bug to push it globally. If not, patch lldb to support non-c++11, or leave it up to the user to fiddle with the CXXFLAGS, where we only point the user by to proper docs. To be honest, I do not really see a link between the let's bring in a new version of compiler, it is a bit stricter in some situations, but these were bugs anyway, like missing headers or unfounded assumptions about memcpy() with let's support a new version of language which produces object files with different ABI. Perhaps a Python 2.6 vs. Python 3.3 is a better analogy? Anyway, GCC 4.8 is pretty clear that the C++11's support is still experimental [1] and subject to change [2]. The upstream developers have announced that they plan to break the ABI of the code using C++11 features in 4.9 [3]. Please also note that this is a very complicated problem, much more difficult than code uses C++11's features - it is incompatible. So far, the only known incompatibility is in the way STL is built. The impact of the other changes like the modified signatures of a couple of STL methods is not clear to me (and I did search for an ultimate answer). Even the document listing the breakage [4] does not provide a clear message if you do $FOO, stuff breaks, but $BAR is completely safe. For example, there is no reason for not building e.g. Qt5 with C++11 support. In fact, limiting it to use just the C++98 features would be considered a regression from the perspective of a developer using Qt. Right now, it seems that we shall wait at least for GCC 4.9 to come and for upstream to decide how to solve this properly. Cheers, Jan [1] http://gcc.gnu.org/gcc-4.8/cxx0x_status.html [2] https://lwn.net/Articles/552831/ [3] https://lwn.net/Articles/552750/ [4] http://gcc.gnu.org/wiki/Cxx11AbiCompatibility
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 09:35:14 CEST, Michał Górny wrote: And how is this an issue to the major distributions? Binary distros can do a simple switch with standard all-package upgrade and forget about it. Like they usually do. Only people who built from sources have to think about it. Wrong; the binary-only distributions have to ship a ton of compat-$foo packages, if only for compatibility with 3rd party software. At least that's what RHEL has been doing for ages. Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On 12/19/13 03:35 PM, Michał Górny wrote: Dnia 2013-12-19, o godz. 15:28:46 C. Bergström cbergst...@pathscale.com napisał(a): On 12/19/13 03:20 PM, Michał Górny wrote: Dnia 2013-12-19, o godz. 00:56:31 C. Bergström cbergst...@pathscale.com napisał(a): On 12/19/13 12:47 AM, Kent Fredric wrote: On 19 December 2013 06:33, Jan Kundrát j...@gentoo.org wrote: I'm worried by the cost of such a policy, though, because we would suddenly have to patch some unknown amount of software Given the nature that changing that CXX Flag globally for all users could cause many packages to spontaneously fail to build, wouldn't that imply that changing that flag would essentially be de-stabilizing the whole tree, and a package being (arch) would no longer be an indication of sane, tested behaviour? This is really the perk of the USE driven process, the granular piecemeal approach that does only as much as necessary, without changing things that are already stable. In practice wouldn't that mean you'd have to add c++11 USE flag to every C++11 application and lib? No. Only the libs that change their ABI in C++11. Best case both build and you end up with a linker problem (can be worked around with compiler patches) /usr/lib64/libboost.so /usr/lib64-c++11/libboost.so What's wrong with this solution: 1. distro-specific compiler patching is wrong, Pragmatically, this needs to be upstream and should have been there already. Get some feedback to see if gcc people are receptive to the idea before testing a gentoo-only patch. If they accept it upstream - backport it. If they tell you f* off - get their feedback on how to deal with it - more belo (this is not a gentoo only problem - this discussion should happen on a more global level...) And how is this an issue to the major distributions? Binary distros can do a simple switch with standard all-package upgrade and forget about it. Like they usually do. Only people who built from sources have to think about it. Umm.. no? Lets use a hypothetical example... libboost.so (or any really popular lib.. Qt..) built with -std=c++11 breaks abi If they don't do some sort of multilib approach - they are only going to build it once and then any consumer of that outside the distro is stuck with their decision. That's probably fine in the predominately C++03 world we have today, but for how long? I expect users on the binary distro just do what they have to work around the problem (go build their whole dependency chain from source). It didn't solve the problem - just made it work for distro packages and pushed it off to the user. My -L rant would depend on the above being used - that's all
Re: [gentoo-dev] How to support C++11 in libraries?
Dnia 2013-12-19, o godz. 09:58:25 Sven Eden sven.e...@gmx.de napisał(a): Am Mittwoch, 18. Dezember 2013, 08:54:47 schrieb Michał Górny: This raises the following question: how do we want to do it? I see two possibilities: a) adding USE=c++11 and USE-deps to all the packages in question, b) doing the switch via synchronous version bump and matching dependencies. (snip) What are your thoughts? I have already switched to C++11 on all my projects ages ago. It offers a lot, and the incompatibilities are rare at best. C++11 is the current standard with the next being worked on already. What is the rationale for staying with C++03 or (worse) C++98 in the first place? Nothing is gained. Only the need to fix what becomes broken. I can agree with that but we need a way to get a smooth transition. So I'd go the reverse way. Make CXXFLAGS=-std=c++11 the default, and only override this for packages that do fishy stuff and break with it. How can we do that? I think the only possibility is to patch gcc and change the default... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] How to support C++11 in libraries?
Dnia 2013-12-19, o godz. 09:43:40 Jan Kundrát j...@gentoo.org napisał(a): On Thursday, 19 December 2013 02:41:55 CEST, hero...@gentoo.org wrote: I'd like to make an analogy to the version bump of gcc[1]. We (gentoo) decide to support c++11 officially or not. If so, open a tracker bug to push it globally. If not, patch lldb to support non-c++11, or leave it up to the user to fiddle with the CXXFLAGS, where we only point the user by to proper docs. To be honest, I do not really see a link between the let's bring in a new version of compiler, it is a bit stricter in some situations, but these were bugs anyway, like missing headers or unfounded assumptions about memcpy() with let's support a new version of language which produces object files with different ABI. Perhaps a Python 2.6 vs. Python 3.3 is a better analogy? Well, it's even worse than that. I think the main difference is that usual gcc/whatever bumps may have resulted in *one* different libstdc++ ABI. People rebuilt all their packages, world went back to normal. The issue here is that gcc is providing two ABIs in parallel, with a -std= switch. And this sucks pretty much... Anyway, GCC 4.8 is pretty clear that the C++11's support is still experimental [1] and subject to change [2]. The upstream developers have announced that they plan to break the ABI of the code using C++11 features in 4.9 [3]. Would it be possible to have a consistent ABI for both C++03 and C++11? The simpler changes like adding new fields can be backported quite easily (even if it would mean having dummy fields in C++03), I have no idea about the more complex changes. Right now, it seems that we shall wait at least for GCC 4.9 to come and for upstream to decide how to solve this properly. Well, if they considered the C++11 ABI in gcc-4.9 stable, we could consider changing the default to C++11. Then, we could do our bump/switch thing as a matter of gcc-4.9 upgrade problem. And that brings another issue in Gentoo -- gcc-config. AFAIR this tool is completely insane and switches libstdc++ along with gcc version. As a result, after switching to a gcc version with different C++ ABI, installed software gets broken. And you can't really fix it without going through the broken-system state or some hackery. It would be much better if the switching was done by some ebuild. We could then use subslots to force rebuilds of stuff using libstdc++. Well, more than that, preserved-libs would prevent disappearing old libstdc++ from breaking stuff. But well, that's just my wishes... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] New global use flags: 3dnowext, mmxext, ssse3, sse4_1, avx, avx2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 15 Dec 2013 15:34:13 -0800 Matt Turner matts...@gentoo.org wrote: And at the same time, clean up the descriptions of the other flags. The existing descriptions were clearly copy-and-pasted and contained things like faster floating point optimization for SSSE3 capable chips when SSSE3 didn't add any floating point instructions. 3dnow: Use the 3DNow! instruction set 3dnowext: Use the Enhanced 3DNow! instruction set mmx: Use the MMX instruction set mmxext: Use the Extended MMX instruction set (intersection of Enhanced 3DNow! and SSE instruction sets) (3dnowext or sse in cpuinfo) sse: Use the SSE instruction set sse2: Use the SSE2 instruction set sse3: Use the SSE3 instruction set (pni in cpuinfo) ssse3: Use the SSSE3 instruction set sse4_1: Use the SSE 4.1 instruction set avx: Use the AVX instruction set avx2: Use the AVX2 instruction set I'll make these changes in a few days. We don't seem to have a use of an sse4_2 USE flag anywhere yet, notably. Unfortunately we do have two uses of sse4, which should be corrected to be more specific: media-libs/freeverb3 net-misc/bfgminer Is it possible to make this in a way so all the instruction set use flags can be read from the use.desc by some simple epression? Like 1. is prefix/postfix for Instruction Set or 2. include the \sinstruction set\s in the description? or 3. have them listed in special file for that or 4. whatever we can agree on is the proper way. I'm asking because https://github.com/yaccz/cufd - -- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJSsuKDAAoJEIN+7RD5ejahBlkH+wRiFLAzxazKQ9a/jdpYOeJr j4uY8Q9iAu/4xK3QMXscosaShrz5bW/XGAxRvfT0pqAe8APUrQTw5V+0cFX/yVJ1 2FQBSPgGXPKyq/AQQ6kPlwsQaCVaYxcWA5bOv+dxfVsEcSMYSQsGeX1BdK2S7wHN h6upIw3qFWln75TLUcO52PHR9YNgWTYZvqJWmaLJDDXBDzcuJAVmLJLtf+ketiCK SjNxZlUQpKQzgszb3dTUPeMSbpPuiCNRG9JFG/q8eXlrfLt9qygJvYpFn7OKmEem 8Bmc1LeERhDEvxCb+xAJDFF4UTHNOpj5H57EMmuakiIrEd4f+xMUK4lJtvRTpbU= =25vk -END PGP SIGNATURE-
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 09:44:38 CEST, C. Bergström wrote: libboost.so (or any really popular lib.. Qt..) built with -std=c++11 breaks abi As I said, the problem is more complicated. Qt5 built with the C++11 support does not break its ABI compared to usign the C++98 mode. Boost is in a category of its own because they do not provide a stable ABI to begin with. Jan
Re: [gentoo-dev] How to support C++11 in libraries?
Michał Górny mgo...@gentoo.org writes: And that brings another issue in Gentoo -- gcc-config. AFAIR this tool is completely insane and switches libstdc++ along with gcc version. As a result, after switching to a gcc version with different C++ ABI, installed software gets broken. And you can't really fix it without going through the broken-system state or some hackery. Not that insane. Packages linked with libstdc++ are not crucial in Gentoo, and can be rebuilt with emerge -e @world. Although it's a bad idea for everybody to do so, the systems without emerge -e @world for two years is likely to suck anyway. It just reflects the fact that the world is not perfect. pgp5ze1bLsmnb.pgp Description: PGP signature
Re: [gentoo-dev] How to support C++11 in libraries?
Dnia 2013-12-19, o godz. 22:47:50 hero...@gentoo.org napisał(a): Michał Górny mgo...@gentoo.org writes: And that brings another issue in Gentoo -- gcc-config. AFAIR this tool is completely insane and switches libstdc++ along with gcc version. As a result, after switching to a gcc version with different C++ ABI, installed software gets broken. And you can't really fix it without going through the broken-system state or some hackery. Not that insane. Packages linked with libstdc++ are not crucial in Gentoo, and can be rebuilt with emerge -e @world. Although it's a bad idea for everybody to do so, the systems without emerge -e @world for two years is likely to suck anyway. I think you are getting it the other way around. It's not 'we do not need to support C++ properly because there are no C++ packages crucial to Gentoo'. It's rather 'we have no crucial C++ packages because C++ support in Gentoo is broken by design'. It is a limitation, not a reason to keep stuff buggy. Think of paludis as a good example. People who'd like to use Paludis will end up with broken package manager from time to time. How are they supposed to rebuild it without a working package manager? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] How to support C++11 in libraries?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/12/13 04:07 AM, Michał Górny wrote: Dnia 2013-12-19, o godz. 09:58:25 Sven Eden sven.e...@gmx.de napisał(a): So I'd go the reverse way. Make CXXFLAGS=-std=c++11 the default, and only override this for packages that do fishy stuff and break with it. How can we do that? I think the only possibility is to patch gcc and change the default... A change in profiles? 14.0/* adds that to the default CXXFLAGS in base, new stage3's etc are all rolled with this. We recommend migration to 14.0 profile and have a check somewhere about -std=c++11 missing from CXXFLAGS in case it's overridden in make.conf, so users put it in place? Now just a quick question about this; is an emerge -e @world going to be necessary to make end-user systems work after such a change? it's sounding like it would be -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKzCf0ACgkQ2ugaI38ACPBBoAD/Y/e01CuaFf/40HfZMvGoknZg oK9k5kX5HPCB30xNTYUA/jzg6mfTL1h6RYSgitKUQ8un3ewJTV9Nybmgr3nuvxr2 =SBQP -END PGP SIGNATURE-
Re: [gentoo-dev] How to support C++11 in libraries?
Michał Górny mgo...@gentoo.org writes: Think of paludis as a good example. People who'd like to use Paludis will end up with broken package manager from time to time. How are they supposed to rebuild it without a working package manager? Oh, I'm scared. I'll step away and watch out for such situation at all cost. pgpvmL8zTx8IU.pgp Description: PGP signature
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 10:18:55 CEST, Michał Górny wrote: Would it be possible to have a consistent ABI for both C++03 and C++11? The simpler changes like adding new fields can be backported quite easily (even if it would mean having dummy fields in C++03), I have no idea about the more complex changes. I don't know, but from a bystander's point of view, I surely hope that it will be possible. Otherwise there would be no option but providing a multilib-like setup for C++11, after all. Some messages on gcc's ML indicate that there are software vendors who are *very* afraid of doing the SONAME change again. Given that C++11 forbids a refcounted std::string while libstdc++ currently use just that for its implementation, I suspect that the upstream developers have a very interesting problem to solve. (And there's much more.) It is pretty clear to me that even the gcc people have not reach a consensus on how the ABI of the standard library will look like in 4.9, so maybe it is premature for us to talk about how to solve this. The ball is on their side. Well, if they considered the C++11 ABI in gcc-4.9 stable, we could consider changing the default to C++11. Then, we could do our bump/switch thing as a matter of gcc-4.9 upgrade problem. To put things into perspective, *if* the ABI changes and if the new version is compatible between C++98 and C++11, then we're talking something very similar to an upgrade from GCC 3.3. Cheers, Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 16:00:13 CEST, Ian Stakenvicius wrote: A change in profiles? 14.0/* adds that to the default CXXFLAGS in base, new stage3's etc are all rolled with this. We recommend migration to 14.0 profile and have a check somewhere about -std=c++11 missing from CXXFLAGS in case it's overridden in make.conf, so users put it in place? Before you invest any more time in this, please understand that C++98 and C++11 are source-incompatible. There is no way to expect that a package builds fine when you throw -std=c++11 on it. And even if you patched them all, you are breaking an unknown number of 3rd party software over which you have exactly zero control. Also note that as of gcc 4.8, the C++11 support is still labeled as experimental and upstream developers announced they will introduce ABI breaks in future. With kind regards, Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On 12/19/2013 10:00 AM, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/12/13 04:07 AM, Michał Górny wrote: Dnia 2013-12-19, o godz. 09:58:25 Sven Eden sven.e...@gmx.de napisał(a): So I'd go the reverse way. Make CXXFLAGS=-std=c++11 the default, and only override this for packages that do fishy stuff and break with it. How can we do that? I think the only possibility is to patch gcc and change the default... A change in profiles? 14.0/* adds that to the default CXXFLAGS in base, new stage3's etc are all rolled with this. We recommend migration to 14.0 profile and have a check somewhere about -std=c++11 missing from CXXFLAGS in case it's overridden in make.conf, so users put it in place? If we are going to make -std=c++11 the default, I would do it in the gcc spec files and then override it with CXXFLAGS if USE=-c++11. -- 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
Re: [gentoo-dev] How to support C++11 in libraries?
On 12/19/2013 10:23 AM, Jan Kundrát wrote: On Thursday, 19 December 2013 16:00:13 CEST, Ian Stakenvicius wrote: A change in profiles? 14.0/* adds that to the default CXXFLAGS in base, new stage3's etc are all rolled with this. We recommend migration to 14.0 profile and have a check somewhere about -std=c++11 missing from CXXFLAGS in case it's overridden in make.conf, so users put it in place? Before you invest any more time in this, please understand that C++98 and C++11 are source-incompatible. There is no way to expect that a package builds fine when you throw -std=c++11 on it. And even if you patched them all, you are breaking an unknown number of 3rd party software over which you have exactly zero control. Also note that as of gcc 4.8, the C++11 support is still labeled as experimental and upstream developers announced they will introduce ABI breaks in future. With kind regards, Jan I would look to gcc-4.9 for C++11. By that point many upstream providers will start to feel the pressure and patch for us. -- 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
Re: [gentoo-dev] How to support C++11 in libraries?
On 12/19/13 16:17, Jan Kundrát wrote: On Thursday, 19 December 2013 10:18:55 CEST, Michał Górny wrote: Would it be possible to have a consistent ABI for both C++03 and C++11? The simpler changes like adding new fields can be backported quite easily (even if it would mean having dummy fields in C++03), I have no idea about the more complex changes. I don't know, but from a bystander's point of view, I surely hope that it will be possible. Otherwise there would be no option but providing a multilib-like setup for C++11, after all. Some messages on gcc's ML indicate that there are software vendors who are *very* afraid of doing the SONAME change again. Given that C++11 forbids a refcounted std::string while libstdc++ currently use just that for its implementation, I suspect that the upstream developers have a very interesting problem to solve. (And there's much more.) It is pretty clear to me that even the gcc people have not reach a consensus on how the ABI of the standard library will look like in 4.9, so maybe it is premature for us to talk about how to solve this. The ball is on their side. Well, if they considered the C++11 ABI in gcc-4.9 stable, we could consider changing the default to C++11. Then, we could do our bump/switch thing as a matter of gcc-4.9 upgrade problem. To put things into perspective, *if* the ABI changes and if the new version is compatible between C++98 and C++11, then we're talking something very similar to an upgrade from GCC 3.3. Cheers, Jan just a question, what would do -fabi-version=6 added to CXXFLAGS even w/o C++11?
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 17:29:19 CEST, viv...@gmail.com wrote: just a question, what would do -fabi-version=6 added to CXXFLAGS even w/o C++11? I believe that -fabi-version is for low level bits at the level of e.g. identifier mangling. It cannot affect whether a std::string is refcounted or not, or whether a std::list contains a member for O(1) size() behavior -- these require modifications to the actual memory layout of the class. Cheers, Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Thu, 19 Dec 2013 22:47:50 +0900 hero...@gentoo.org wrote: Michał Górny mgo...@gentoo.org writes: And that brings another issue in Gentoo -- gcc-config. AFAIR this tool is completely insane and switches libstdc++ along with gcc version. As a result, after switching to a gcc version with different C++ ABI, installed software gets broken. And you can't really fix it without going through the broken-system state or some hackery. Not that insane. Packages linked with libstdc++ are not crucial in Gentoo, and can be rebuilt with emerge -e @world. Although it's a bad idea for everybody to do so, the systems without emerge -e @world for two years is likely to suck anyway. It just reflects the fact that the world is not perfect. Gentoo is the only distribution that gets this wrong. It's self inflicted, not a problem with the world. -- Ciaran McCreesh signature.asc Description: PGP signature
