GCC 5 for 14.10 (wily) on July 31

David Henningsson david.henningsson at canonical.com
Thu Jul 23 15:44:38 UTC 2015


On 2015-07-23 17:02, Dimitri John Ledkov wrote:
> 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.

Cool, thanks for the explanation.

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

The above clears up a lot.

I'm thinking whether or not it is possible for an ISV to support both 
abis in the same deb. Maybe if the ISV ships two different executables 
(and optionally, two sets of included libraries) and some wrapper script 
that selects one or the other at program startup time?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic




More information about the Ubuntu-devel-discuss mailing list