| 1 |
On Mon, 2 Jan 2017 21:34:03 +0000 |
| 2 |
"Justin <jlec>" <jlec@g.o> wrote: |
| 3 |
|
| 4 |
> Hi all |
| 5 |
> |
| 6 |
> How about making USE="c++11" a global USE? |
| 7 |
> |
| 8 |
> Description: Build using the C++11 standard. |
| 9 |
> |
| 10 |
> [...] |
| 11 |
> |
| 12 |
> Seems to be very consistent in usage. |
| 13 |
|
| 14 |
...and yet a very bad idea. |
| 15 |
|
| 16 |
As blueness pointed out, there's a major ABI incompatibility problem |
| 17 |
going on here. For gcc < 5, packages built with -std=c++11 were |
| 18 |
frequently ABI-incompatible with those built with -std=c++98. In gcc-5 |
| 19 |
the ABI compatibility was improved but then packages built with gcc-5 |
| 20 |
are incompatible with those built with earlier gcc versions ;-). |
| 21 |
|
| 22 |
So the flag really makes sense only for gcc < 5 world where it could be |
| 23 |
used to solve the ABI incompatibility problem by enforcing consistent |
| 24 |
standard throughout dependency chains. Which means adding the flag to |
| 25 |
pretty much every C++ library that exposes stdlib types in ABI, and all |
| 26 |
their reverse dependencies using those ABIs including appropriate USE |
| 27 |
dependencies. |
| 28 |
|
| 29 |
This is a lot of work with potential confusion of users included for |
| 30 |
a temporary benefit. It's usually better to just bump the C++ standard |
| 31 |
consistently throughout the dependency chain and use subslots to force |
| 32 |
rebuilds. This avoids the necessity of explicit action on user part, |
| 33 |
and adding flags that will eventually be removed in the future. |
| 34 |
|
| 35 |
Plus, it may save us from some of the usual 'why did you remove |
| 36 |
support for this nice old C++ standard from this package?! Upstream |
| 37 |
still supports it! I don't like new standards, the old one worked |
| 38 |
fine for me and now the crappy program I wrote breaks!' bikeshed. |
| 39 |
|
| 40 |
Also note that in order to solve the problem properly we'd really use |
| 41 |
flags to control/expose ABI rather than the C++ standard alone. |
| 42 |
Something like one-of [ gcc4-c++98 gcc4-c++11 gcc5 [gcc6?] libcxx-1 ]. |
| 43 |
However, that's a lot of work, and really will just move the burden |
| 44 |
from developers to users having to play with ABIs post gcc upgrades |
| 45 |
(well, maybe gcc-config could handle that by default...). |
| 46 |
|
| 47 |
In any case, nobody really volunteered to do the work on that or even |
| 48 |
perform the complete research. |
| 49 |
|
| 50 |
-- |
| 51 |
Best regards, |
| 52 |
Michał Górny |
| 53 |
<http://dev.gentoo.org/~mgorny/> |
Archives