Re: [gentoo-dev] How to support C++11 in libraries?
Am Donnerstag, 19. Dezember 2013, 16:23:08 schrieb Jan Kundrát: 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. No. If you do something against the standard that is working due to lack of control when compiling with -std=c++98, then your source code is severly broken. Most developers will use C++03 (plus tr1) anyway, won't they? And no, the languages are _not_ source-incompatible. That would be a scandal! But if you have your C++98/03 code, and do what most developers do and let your console be flooded with warnings you ignore, you must not be surprised, if the compilation fails when you decide to throw -std=c++11 -Wall -Wextra -Wpedantic -fsanitize=address -fsanitize=thread with gcc 4.8.2 at it. There is absolutely no reason to expect a compilation to fail with C++11, if it went well with C++03 and -Wall -Wextra -pedantic. If you try to outsmart your compiler, it will get it's revenge very soon and very hard. And according to [1] it goes even further: Quote: If you use C++11 then in general you can combine C++11 code built with GCC 4.X and C++03 code built with any GCC, but there is not the same guarantee that you can combine with C++11 code built with GCC 4.Y or GCC 4.Z, because the C++11 features are not all stable yet (e.g. for GCC 4.9 I'm about to add a new virtual function to a base class in future.) This is why C++11 support is still labelled experimental, because it would be worse to claim it's stable and then have to break the ABI. So basically C++11 - C++03 is no problem at all (unless you *export* certain symbols [2]), but combining C++11 from different gcc versions is nowhere guaranteed to work. Cheers Sven [1] : https://lwn.net/Articles/552831/ [2] : http://gcc.gnu.org/wiki/Cxx11AbiCompatibility signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to support C++11 in libraries?
On Friday, 20 December 2013 10:00:43 CEST, Martin Vaeth wrote: The example with string reference-counters which you gave is IMHO typical; one would really need to write strange code to make it work *with* reference counters but break without. Hard to believe that this happens in practice. What *will* happen in practice is that the execution speed changes (probably getting slower, but there might also be exceptions). You have not considered the implications of the updated requirements. With std::string, this might be hard to understand within all the layers of template wrapping, but consider std::list instead. The old (C++98/C++03) std::list is implemented by containing exactly one member, the struct _List_node_base. This struct has exactly two pointers inside, one for the next item and one for the last. This layout cannot be changed without breaking the binary compatibility; it is effectively made public because GCC's standard library does not use the PIMPL idiom. Now, this particular layout (which we just established cannot be changed without breaking the ABI) means that std::list::size() has O(n) time cost simply because it has to traverse the whole list to compute the number of items. The C++11 standard, however, mandates the time complexity to be O(1). This means that there will be a very visible change, at least for std::list. I won't speculate on how the upstream is going to solve this, but I do not expect that the end result will allow linking a translation unit built for C++98 by GCC = 4.8 with one built for C++11 by the new compiler. Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Friday, 20 December 2013 12:56:43 CEST, Sven Eden wrote:
And no, the languages are _not_ source-incompatible. That would be a
scandal!
You might argue about this, but that doesn't change these facts. This is
absolutely valid C++98 program:
jkt@svist ~ $ cat foo.cpp
int main() {
auto int foo;
return 0;
}
jkt@svist ~ $ g++ -std=c++98 -pedantic foo.cpp
jkt@svist ~ $ echo $?
0
...which will *not* build under the C++11 mode:
jkt@svist ~ $ g++ -std=c++0x foo.cpp
foo.cpp: In function ‘int main()’:
foo.cpp:2:14: error: two or more data types in declaration of ‘foo’
Yes, -Wc++0x-compat warns about this, yes, it's included in -Wall, but it
does not change the fact that there *is* code out there which does conform
to C++98 standard, does *not* try to outsmart the compiler, and which
will not build in the C++11 mode. Do we really have to be having this
discussion?
Cheers,
Jan
Re: [gentoo-dev] How to support C++11 in libraries?
2013/12/20 Jan Kundrát j...@gentoo.org:
On Friday, 20 December 2013 12:56:43 CEST, Sven Eden wrote:
And no, the languages are _not_ source-incompatible. That would be a
scandal!
You might argue about this, but that doesn't change these facts. This is
absolutely valid C++98 program:
jkt@svist ~ $ cat foo.cpp int main() {
auto int foo;
return 0;
}
jkt@svist ~ $ g++ -std=c++98 -pedantic foo.cpp
jkt@svist ~ $ echo $?
0
...which will *not* build under the C++11 mode:
jkt@svist ~ $ g++ -std=c++0x foo.cpp
foo.cpp: In function ‘int main()’:
foo.cpp:2:14: error: two or more data types in declaration of ‘foo’
Yes, -Wc++0x-compat warns about this, yes, it's included in -Wall, but it
does not change the fact that there *is* code out there which does conform
to C++98 standard, does *not* try to outsmart the compiler, and which will
not build in the C++11 mode. Do we really have to be having this discussion?
The C++ Committee considered this exact case in relation to the new
meaning of `auto` and decided that such code doesn't really exist in
the wild. You won't hit auto-related issues in almost all packages in
Portage I guess.
There are more obscure cases of incompatibility though, with more
obscure error messages, like with autogenerated move ctors and the
likes. I've hitted it myself a couple of times in more or less complex
template code, but can't think of an example off the top of my head
unfortunately.
--
Georg Rudoy
LeechCraft — http://leechcraft.org
Re: [gentoo-dev] How to support C++11 in libraries?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/12/13 06:56 AM, Sven Eden wrote: So basically C++11 - C++03 is no problem at all (unless you *export* certain symbols [2]), but combining C++11 from different gcc versions is nowhere guaranteed to work. Cheers Sven [1] : https://lwn.net/Articles/552831/ [2] : http://gcc.gnu.org/wiki/Cxx11AbiCompatibility Aha... so what we should probably be doing then is filtering out - --std=c++11 until gcc-4.9 or whatever version is released, that will standardize things, so that we don't end up with systems that have a mix-and-match. And probably alert users using earlier versions of gcc that if they enable --std=c++11, they should expect to 'emerge -e @world' on any compiler switch. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlK0XdEACgkQ2ugaI38ACPB2WgEAtnLeonyTFCF5cMEIi0kSIHZ/ RZcgjzRbojT3YejvMmkA/2v/qC7Cy58QAgz7oEC5z+KvPUVBJ79Ana0+rrPoq9TM =pn2S -END PGP SIGNATURE-
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] 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
Re: [gentoo-dev] How to support C++11 in libraries?
On 12/18/13 02:54 PM, Michał Górny wrote: Hello, folks. Hi snip Basically, I've hit this with sys-devel/llvm. A user has requested lldb support to be enabled in the ebuild [2]. Sadly, lldb requires C++11 to be used, and this means that whole LLVM needs to become C++11 enabled. And then, it would be at least recommended that all reverse deps become C++11 enabled as well. /* Personally, I think lldb is pooh (bloated mess that has poor internal design, offers little or no logical features that can't be accomplished with source access+printf and takes a needlessly long time to compile as a result) */ If the only driving motivation is lldb then I think this isn't worth the effort and I wonder what may be incompatible as a result. Long term it certainly should happen - I can't/won't argue or disagree with the long term merits, but when.. and who will do all that work.. Just a heads up that clang/llvm will (have in svn trunk) force building with c++11 for the next major release (6 months from now). So unless some 3rd party goes and backports or removes the c++11 pieces - this will add to the list of c++11 only software in the near future.
Re: [gentoo-dev] How to support C++11 in libraries?
Hey, Michał, Michał Górny mgo...@gentoo.org writes: a) adding USE=c++11 and USE-deps to all the packages in question, I think it is better achieved by a (simple and stupid) global CXXFLAGS. Adding an extra USE flag feels a little over-engineering. Any anyway, if it is only for lldb, a piece of elog conveying a preferred solution would suffice. b) doing the switch via synchronous version bump and matching dependencies. This sounds tedious to maintain. Benda pgpdHEtePjCLe.pgp Description: PGP signature
Re: [gentoo-dev] How to support C++11 in libraries?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/12/13 02:54 AM, Michał Górny wrote: Hello, folks. As some of you are already aware, the C++11 standard brought a few changes to the C++ standard library. As a result, the standard library used in C++11 mode has a different ABI than the one used in pre-C++11 mode. And this means that libraries that use some of standard C++ types in their APIs also have different ABIs depending on the C++ standard used to build them. This is somehow explained in [1]. As a result, if a single library suffers that, its reverse dependencies need to be built with the same C++ standard. And then, those can force even more dependencies and you may guess where this is going. Basically, I've hit this with sys-devel/llvm. A user has requested lldb support to be enabled in the ebuild [2]. Sadly, lldb requires C++11 to be used, and this means that whole LLVM needs to become C++11 enabled. And then, it would be at least recommended that all reverse deps become C++11 enabled as well. [1]:http://gcc.gnu.org/wiki/Cxx11AbiCompatibility [2]:https://bugs.gentoo.org/show_bug.cgi?id=464354 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. I think that the variant a) is simpler. It goes like this: 1) we add 'sys-devel/llvm[-c++11(-)]' deps to everything that uses it, 2) we add USE=c++11 to llvm, 3) we add USE=c++11 and 'sys-devel/llvm[c++11=(-)]' deps to newest version of everything that uses it. The advantage is that plain users may just keep USE=c++11 disabled as it is by default, and avoid hitting some issues with non-tree packages and so on. At some point, we'll probably want to remove non-C++11 support completely. Then we could start by use.forcing the flag, changing deps in packages and so on. I think variant A is probably a better solution all around, not least because this type of choice is almost a profile-level decision and a global USE flag setting seems an appropriate way to ensure it works. Plus, the use flag method allows those that want to fiddle with it per-package to be able to do so while still guaranteeing the deptree is properly synchronized as per the version. variant B does offer the nice ability to just force it and therefore not give end-users this new flag to worry about, but I forsee that we will have conflicts with upgrading/downgrading package between the pre- and post-C++11 border. If we were a versioned distro this would be the way to go, but -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF0EAREIAAYFAlKxsOsACgkQ2ugaI38ACPAW7wD49p8JqopRARN4h6lB8+Z5bXs2 VB8Gb0wPMJouAuwpaAD8CDAa4L7w9KP9QXXaSnJrojdBmk9bZQ0GDJL26/5sqf4= =01b1 -END PGP SIGNATURE-
Re: [gentoo-dev] How to support C++11 in libraries?
On Wednesday, 18 December 2013 14:58:07 CEST, hero...@gentoo.org wrote: I think it is better achieved by a (simple and stupid) global CXXFLAGS. Adding an extra USE flag feels a little over-engineering. What compiler flag do you propose to use? Note that --std=c++11 will not work. Cheers, Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On 12/18/13 11:29 PM, Jan Kundrát wrote: On Wednesday, 18 December 2013 14:58:07 CEST, hero...@gentoo.org wrote: I think it is better achieved by a (simple and stupid) global CXXFLAGS. Adding an extra USE flag feels a little over-engineering. What compiler flag do you propose to use? Note that --std=c++11 will not work. From the perspective of a compiler vendor - I must ask why not?
Re: [gentoo-dev] How to support C++11 in libraries?
On Wednesday, 18 December 2013 17:37:56 CEST, C. Bergström wrote: From the perspective of a compiler vendor - I must ask why not? There is code out there which builds fine under C++98, but fails to build when C++11 is enabled (as but one exmaple, have a look at [1]). [1] https://bugs.freedesktop.org/show_bug.cgi?id=46147
Re: [gentoo-dev] How to support C++11 in libraries?
On 12/18/13 11:50 PM, Jan Kundrát wrote: On Wednesday, 18 December 2013 17:37:56 CEST, C. Bergström wrote: From the perspective of a compiler vendor - I must ask why not? There is code out there which builds fine under C++98, but fails to build when C++11 is enabled (as but one exmaple, have a look at [1]). If moving to C++11 - Isn't that considered just part of the work along the path? There's some clang tools to help with the migration, but I don't think anyone expects it to be zero work. The flag is just a way to a) enable building programs that can be built with c++11 b) flush out the culprits in the cases it can't be. If (b) is a bug - how else to find it easily?
Re: [gentoo-dev] How to support C++11 in libraries?
On Wednesday, 18 December 2013 18:05:46 CEST, C. Bergström wrote: If moving to C++11 - Isn't that considered just part of the work along the path? There's some clang tools to help with the migration, but I don't think anyone expects it to be zero work. The flag is just a way to a) enable building programs that can be built with c++11 b) flush out the culprits in the cases it can't be. If (b) is a bug - how else to find it easily? This perspective is interesting (and I admit that I tend to like it) -- considering packages which won't build with C++11 to be buggy. I'm worried by the cost of such a policy, though, because we would suddenly have to patch some unknown amount of software (and I'm pretty sure some upstreams would reject these patches anyway). If we were an enterprise distro with binary compatibility requirements, we would also have to worry about that and either assume that the ABI changes are non-issue in real world, or provide two versions of all C++ libraries. I tried to check how RHEL7 will deal with it, but I wasn't able to find any information about that. It also seems that Fedora hasn't addressed this yet, either. Either way, it is reasonable to assume that some users would like to build their own software and link it with system libraries. It is not reasonable to force these users to build in the C++11 mode, IMHO. Cheers, Jan
Re: [gentoo-dev] How to support C++11 in libraries?
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. -- Kent
Re: [gentoo-dev] How to support C++11 in libraries?
On 12/19/13 12:33 AM, Jan Kundrát wrote: On Wednesday, 18 December 2013 18:05:46 CEST, C. Bergström wrote: If moving to C++11 - Isn't that considered just part of the work along the path? There's some clang tools to help with the migration, but I don't think anyone expects it to be zero work. The flag is just a way to a) enable building programs that can be built with c++11 b) flush out the culprits in the cases it can't be. If (b) is a bug - how else to find it easily? This perspective is interesting (and I admit that I tend to like it) -- considering packages which won't build with C++11 to be buggy. I'm worried by the cost of such a policy, though, because we would suddenly have to patch some unknown amount of software (and I'm pretty sure some upstreams would reject these patches anyway). If we were an enterprise distro with binary compatibility requirements, we would also have to worry about that and either assume that the ABI changes are non-issue in real world, or provide two versions of all C++ libraries. I tried to check how RHEL7 will deal with it, but I wasn't able to find any information about that. It also seems that Fedora hasn't addressed this yet, either. Either way, it is reasonable to assume that some users would like to build their own software and link it with system libraries. It is not reasonable to force these users to build in the C++11 mode, IMHO. I want my cake and eat it too! /* Off the cuff crazy ideas and not meant to be taken too seriously */ In my mind this is almost similar to ABI (incompatibilities) between 32 and 64bit. Why not just (ab)use the multilib approach for c++11? /usr/lib64-c11/ It would possibly (likely) require some patching to clang/g++ when the --std=c++11 flag is used, but might allow the extension of a c++11 library universe while leaving the things which are working today unbroken. The main problem I see with this is proliferation of more crap in /usr/lib* (4 variations instead of just the 2 (32vs64) we have now). (Personally, I'd typically build *only* 64bit versions and 32bit x86 can go to hell...) To get support from the enterprise distros - I'd try to move the discussion of this problem upstream to the LSB level. They will at some point need to solve this same problem as well. It's not like it'll be gentoo specific forever. (You guys are just pioneering and ahead of the curve.. this isn't the same thing as -Omgfast) With this approach - would it make sense to create a new profile? I don't know if a USE flag would in general get pushback, but if the c++11 use flag was used - it would put those libs in /usr/lib64-c11/
Re: [gentoo-dev] How to support C++11 in libraries?
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? I just sent an email with some crazy thoughts - Your point is totally correct - this migration needs to happen while not breaking the whole tree. Logistically - what's the best way to maintain both those ABI at the same time? 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 Worst case only 1 builds this breaks down into generally 2 cases 1. Programs/libs which have intentionally adopted c++11 and don't care about C++03 (clang/llvm/lldb) 2. Programs/libs which can't be compiles with c++11 mode /usr/lib64/libfoo.so
Re: [gentoo-dev] How to support C++11 in libraries?
On 12/18/2013 02:54 AM, Michał Górny wrote: The problem with this solution is that as soon as user upgrades, shklee is forced to use C++11. On the other hand, we get rid of pre-C++11 packages quite transparently, without extra work. What are your thoughts? I assume with variant a you will be able to go back and forth between C++11 abi and pre-C++11. If so, please adopt variant a. -- 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?
Dnia 2013-12-18, o godz. 15:20:10 C. Bergström cbergst...@pathscale.com napisał(a): If the only driving motivation is lldb then I think this isn't worth the effort and I wonder what may be incompatible as a result. Long term it certainly should happen - I can't/won't argue or disagree with the long term merits, but when.. and who will do all that work.. Just a heads up that clang/llvm will (have in svn trunk) force building with c++11 for the next major release (6 months from now). So unless some 3rd party goes and backports or removes the c++11 pieces - this will add to the list of c++11 only software in the near future. Well, last time I was asked to enable C++11 in llvm I answered that I'd delayed it because of the potential ABI incompatibility. While lldb was what made me revisit the subject, I think it's something we will need to handle anyway. I'd rather find a good solution right now while we don't have to hurry. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] How to support C++11 in libraries?
Dnia 2013-12-18, o godz. 22:58:07 hero...@gentoo.org napisał(a): Hey, Michał, Michał Górny mgo...@gentoo.org writes: a) adding USE=c++11 and USE-deps to all the packages in question, I think it is better achieved by a (simple and stupid) global CXXFLAGS. Adding an extra USE flag feels a little over-engineering. This is nowhere near a good solution IMO. First of all, it doesn't give us a way of ensuring ABI compatibility. Users switch the flags and have to rebuild all C++ packages to regain the ABI compatibility. The system ends up borked quite easily. Then, we don't have a good way of finding packages to rebuild. Users could try to find out which libraries used C++ but well... it's nowhere near good. Or they just rebuild everything... Then, many developers just won't bother. Users will be the ones to hit the incompatible package build failures first. Lastly, this gives us no way of switching to C++11 completely without modifying the compiler defaults. Even if we put '-std=c++11' into profiles, most of the people override CXXFLAGS and won't have it. Any anyway, if it is only for lldb, a piece of elog conveying a preferred solution would suffice. elog? I think you mean dying with CXXFLAGS that don't specify the necessary standard. Which is kinda backwards to REQUIRED_USE... And then, simple CXXFLAGS solution would end up breaking users' systems... -- 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 18/12/13 01:10 PM, Anthony G. Basile wrote:
On 12/18/2013 02:54 AM, Michał Górny wrote:
The problem with this solution is that as soon as user upgrades,
shklee is forced to use C++11. On the other hand, we get rid of
pre-C++11 packages quite transparently, without extra work.
What are your thoughts?
I assume with variant a you will be able to go back and forth
between C++11 abi and pre-C++11. If so, please adopt variant a.
It would, but unless it's done in a way similar to multilib's
abi_{x86,amd64,x32} (as was mentioned in the crazy idea post), only
one version would be installed at a time.
(that is, unless I misread the original proposal and both a generic
and a c++11 version would be installed if the flag was enabled -- i
can see the utility to that solution, but I am not a fan of it; better
to convert and patch when it becomes necessary)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlKx6UwACgkQ2ugaI38ACPC26wD/cS7sN4eK67blugKVq/fUDbEv
50PtDy8xdgBp0tFowZwA/3GrPaROmN5XOUf8nW1tuoeuoD5oVH3nIGV/5AotXSZR
=FkC9
-END PGP SIGNATURE-
Re: [gentoo-dev] How to support C++11 in libraries?
Either way, it is reasonable to assume that some users would like to build their own software and link it with system libraries. It is not reasonable to force these users to build in the C++11 mode, IMHO. As far as I understand now you're just forcing users to build in C++03 mode, don't you? -- Georg Rudoy LeechCraft — http://leechcraft.org
Re: [gentoo-dev] How to support C++11 in libraries?
Hey Jan, Jan Kundrát j...@gentoo.org writes: This perspective is interesting (and I admit that I tend to like it) -- considering packages which won't build with C++11 to be buggy. I'm worried by the cost of such a policy, though, because we would suddenly have to patch some unknown amount of software (and I'm pretty sure some upstreams would reject these patches anyway). If we were an enterprise distro with binary compatibility requirements, we would also have to worry about that and either assume that the ABI changes are non-issue in real world, or provide two versions of all C++ libraries. I tried to check how RHEL7 will deal with it, but I wasn't able to find any information about that. It also seems that Fedora hasn't addressed this yet, either. Either way, it is reasonable to assume that some users would like to build their own software and link it with system libraries. It is not reasonable to force these users to build in the C++11 mode, IMHO. 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. There is no problem to introduce a new USE flag for a new ABI. I am concerned with too many ABIs for an average ebuild keeper to maintain. Benda 1. https://bugs.gentoo.org/show_bug.cgi?id=gcc-4.8
Re: [gentoo-dev] How to support C++11 in libraries?
C. Bergström cbergst...@pathscale.com writes: 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 This is the right way to do, but as scary as our multilib where a couple of USE flags are introduced to every package globally.
Re: [gentoo-dev] How to support C++11 in libraries?
Michał Górny mgo...@gentoo.org writes: This is nowhere near a good solution IMO. First of all, it doesn't give us a way of ensuring ABI compatibility. Users switch the flags and have to rebuild all C++ packages to regain the ABI compatibility. The system ends up borked quite easily. Then, we don't have a good way of finding packages to rebuild. Users could try to find out which libraries used C++ but well... it's nowhere near good. Or they just rebuild everything... Then, many developers just won't bother. Users will be the ones to hit the incompatible package build failures first. Lastly, this gives us no way of switching to C++11 completely without modifying the compiler defaults. Even if we put '-std=c++11' into profiles, most of the people override CXXFLAGS and won't have it. Any anyway, if it is only for lldb, a piece of elog conveying a preferred solution would suffice. elog? I think you mean dying with CXXFLAGS that don't specify the necessary standard. Which is kinda backwards to REQUIRED_USE... And then, simple CXXFLAGS solution would end up breaking users' systems... Michał, I am totally agree with you. This approach will leave lots of dirty tricks to the users. Therefore this is a decision between whether the devs or the users do this heavy lift. If the the reason is only lldb and less than 10 other ebuilds, I feel it not worth the develop and maintenace time. And if you have only met with this problem twice, I suggest playing with it by the simplest solution (via CXXFLAGS) for a while to avoid early optimization. This is just my honest view on simple vs complex. Given the expertise you hold in the realm of ABI, introducing a new ABI to maintain might not be a big deal to you. Then I understand. Cheers, Benda pgpiPL6Z_CKNV.pgp Description: PGP signature
