| 1 |
On 30/10/14 15:06, Jan Kundrát wrote: |
| 2 |
> On Saturday, 25 October 2014 12:47:21 CEST, Luca Barbato wrote: |
| 3 |
>> The ABI mismatch is due the library not being versioned properly as |
| 4 |
>> "usual"? |
| 5 |
> |
| 6 |
> Please note that this would be a "hard thing to do". This is not just a |
| 7 |
> matter of calling an appropriate version of a given function; there are |
| 8 |
> no guarantees about the internal layout of the data structures, etc. |
| 9 |
> Furthermore, portions of C++ code might be inlined, so whenever you have |
| 10 |
> a library compiled with different GCC versions, these cannot exchange |
| 11 |
> any data which embed a C++11 data type inside. That's quite a bummer -- |
| 12 |
> std::string and std::list have both changed in C++11 (forbidden |
| 13 |
> ref-counting of std::string and O(1) size of std::list::size()). The |
| 14 |
> upstream's promise is that the ABI will eventually ebcome stable when |
| 15 |
> they remove the "experimental" label on their C++11 support. |
| 16 |
> |
| 17 |
> I suspect that the only solution would be a full ABI version number |
| 18 |
> change at that time, though, and people want to avoid doing this because |
| 19 |
> that will of course break all C++ programs out there. It would be |
| 20 |
> terrific if the GCC guys provided a reasonable roadmap, because saying |
| 21 |
> "we support C++11" while also saying "don't combine code built by 4.7 |
| 22 |
> and 4.8, that's totally unsupported" is a bit strange. Yes, limited time |
| 23 |
> and limited manpower and what not, but it's still something which makes |
| 24 |
> using all of the C++11 features a very risky business. |
| 25 |
|
| 26 |
And obviously providing libstdc++ and libstdc++11 (and matching headers) |
| 27 |
is not an option =\ |
| 28 |
|
| 29 |
_quite_ annoying indeed |
| 30 |
|
| 31 |
lu - hoping rust won't have such issues. |
Archives