GCC 5 for 14.10 (wily) on July 31

Dimitri John Ledkov xnox at ubuntu.com
Thu Jul 23 15:02:25 UTC 2015


On 23 July 2015 at 15:30, David Henningsson
<david.henningsson at canonical.com> wrote:
>
>
> On 2015-07-23 15:42, Dimitri John Ledkov wrote:
>>
>> On 23 July 2015 at 12:39, David Henningsson
>> <david.henningsson at canonical.com> wrote:
>>>
>>>
>>>
>>> On 2015-07-20 23:44, Matthias Klose wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> We are currently preparing the switch to GCC 5 as the default compiler
>>>> for
>>>> 14.10
>>>> (wily).  Unlike earlier updates to newer compiler versions, which only
>>>> required
>>>> updating packages to newer language standards, this time we have a
>>>> partial
>>>> ABI
>>>> transition in the standard C++ library (libstdc++6).
>>>
>>>
>>>
>>> That sounds scary, but maybe it's not as scary as it sounds. Will this
>>> also
>>> affect everyone outside the main repo distributing binary packages (e g,
>>> Google Hangout)?
>>>
>>> How will the versioning of libstdc++ look like, in order to make sure no
>>> packages are linking against a libstdc++ they are incompatible with?
>>
>>
>> So libstdc++ 98 abi is not broken, and old 98abi symbols are still
>> provided.
>> However the c11 abi was broken (there are small number of packages
>> that use c11 abi from before 5.x release).
>> And finally newly compiled libraries against the new libstdc++ will
>> use c11 abi, not 98abi.
>> Depending on what those libraries export as an api, they may become
>> incompatible (e.g. if they wrapped std::string, it will now become a
>> different one).
>>
>> Do you have a list of libraries that e.g. google hangouts link
>> against? if it only links against libstdc++ in 98abi it should
>> continue to work.
>
>
> Google Hangout was merely an example. I suppose we have several proprietary
> applications in Ubuntu Software Center too, that might suffer from the same
> problem?
>
> Anyhow, it seems a little scary if there is a possibility that packages will
> be installable, but then randomly crash (or worse, cause a se curity hole) at
> runtime. Or is this fixed by versioning somehow, e g at Debian packaging
> level, file extension symlink level, or symbol linking level?
>

I am still confused what you are alluding to.

Checkout https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

There is no abi break in libstdc++.

A lot of libraries are going to get a soname bump in wily, e.g. icu /
boost / etc. And e.g. boost1.58 in wily will only support c++11 abi,
thus in wily and up one would not be able to compile 98abi boost
binaries. However existing binaries, e.g. with kept-back boost1.55
from e.g. trusty would continue to run, as libstdc++ in wily still
provides the 98abi for old binaries.

There is no break in the abi in libstdc++ and other libraries will get
soname bump. Thus if one has correct depedencies declared e.g. in the
app-store, they will either work, or become uninstallable on the
client machines with wily only. Upon upgrades, apt will simply keep
back old ABI libraries thus old stuff should continue to work.

Do you have an actual concrete example that you have a query about
and/or something you don't understand?

Please re-read
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
https://wiki.debian.org/GCC5
https://wiki.ubuntu.com/GCC5

It should explain everything.

-- 
Regards,

Dimitri.




More information about the Ubuntu-devel-discuss mailing list