ubuntu-phone team mailing list archive

[James Henstridge <james.henstridge@xxxxxxxxxxxxx>]

On 16 July 2015 at 15:26, Steve Langasek <steve.langasek@xxxxxxxxxxxxx> wrote:
> Hi all,
>
> As Matthias posted about on ubuntu-devel last week[1], we are facing a
> transition with the update to gcc 5 in wily.  Many C++ libraries will need
> rebuilds for an ABI transition due to changes in the C++11 support in gcc 5.
>
> We have a silo in progress for this, so that this transition can be staged
> in a way that's minimally disruptive to the phone builds in wily, but we
> need the phone team's help this transition complete in a timely fashion.
> There are a number of bug reports filed a while ago for packages that have
> build-dependencies on g++-4.9, and need to be updated.  The bugs are here:
>
>   https://bugs.launchpad.net/ubuntu/+bugs?field.tag=lsd-cxx11
>
> the full list of affected packages is:
>
>   dbus-cpp
>   indicator-datetime
>   indicator-display
>   indicator-location
>   indicator-network
>   indicator-transfer
>   location-service
>   media-hub
>   mediascanner2
>   mir
>   net-cpp
>   platform-api
>   process-cpp
>   qtmir
>   qtmir-gles
>   trust-store
>   unity-api
>   unity-scope-mediascanner
>   unity-scopes-api
>   unity-system-compositor
>   unity8
>
> The bugs are now marked critical, and there's good progress on a number of
> them with merge proposals raised, but we need these to be fixed as soon as
> possible; because once fixed, we will need to see which of these packages
> fail to build with gcc 5.  There are already a number of packages failing to
> build, which will need to be fixed up as shown in the silo ppa:
>
>   https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages
>
> And once the above packages have been adjusted not to use g++-4.9, we may
> see a few more build failures.
>
> We'll prepare a list of all failing packages shortly to discuss with the
> responsible teams, but in the meantime if you want to get started on fixing
> the build failures shown there, there's no time like the present!

I think the gorilla in the room here is click packages.  For example,
if we rebuild unity-scopes-api like this then every scope in the app
store and ones preloaded in custom images will fail to load due to
dynamic linking errors.

Is that actually the intention here?  If it is intended and we are
bumping the framework version and dropping support for old frameworks,
have we sorted out how developers will be able to ship multiple
versions of their application on the store yet?

If we don't want to drop support for the old frameworks, then we'll
need to do more than simply remove hard g++-4.9 dependencies: we'll
need to provide parallel installable versions of these libraries (and
for things like scopes, make sure the two versions are interoperable
at the IPC level).

James.