Fwd: Intent to implement: Statically link libc++ on Linux

[Tom Anderson]

Hello chromium-packagers!

Chrome on Linux will soon be switching from libstdc++ to libc++.  It will be statically linked, so this has some implications on package dependencies:

• The dependency on libstdc++ will be removed
• *No* dependency on libc++ will be added
• The minimum libc dependency will be increased from 2.15 to 2.18

If you would like to keep the dependencies as they are, you can build with 'use_custom_libcxx = false' in your args.gn.  Be aware, however, that this configuration will no longer be officially supported on Linux, so it may break and/or require downstream patches in the future.  Upstream bugfixes will probably still be accepted.

Currently there is no way of building using the system libc++, but we may consider adding an option to unbundle if there is real demand.

---------- Forwarded message ----------
From: Nico Weber <tha...@chromium.org>
Date: Thu, Jun 29, 2017 at 11:22 AM
Subject: Intent to implement: Statically link libc++ on Linux
To: Chromium-dev <chromi...@chromium.org>
Cc: Thomas Anderson <thomasa...@chromium.org>

Hi chromium-dev,

We intend to land a CL to switch chrome/linux to statically link against libc++.

https://docs.google.com/document/d/1zmHUXlpGNXB433wHnr40dLwj7c-USsIVlyAeH7vOI9o/edit#heading=h.bfky2xssferh has some notes on the motivation and the implementation. This allows us to use more modern language features, removes one of the blockers for -std=c++14, and makes the performance and memory characteristics of chrome/linux more similar to chrome/android.

Contact emails

tha...@chromium.org, thomasa...@chromium.org

Where will the code live?

Libc++ itself is DEPS’d in to buildtools/third_party/libc++. The build file changes are in various places; the main bit is in build/config/BUILD.gn

Ongoing technical constraints

None

Tracking bug

https://crbug.com/593874

Cheers,

Nico (overhead) & Thomas (most of the implementation)

[Mike Gilbert]

This seems likely to cause problems for distros that build chromium
against system libs that are linked with libstdc++. Having both libc++
and libstdc++ loaded in the same process sounds dangerous.

> --
> You received this message because you are subscribed to the Google Groups
> "chromium-packagers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-packag...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAN2uRqpbs5ALWem9OKkTdzEVSQJ2dFEx1gKzDb9_DvabjJbSoA%40mail.gmail.com.

[Tom Anderson]

On Thu, Jun 29, 2017 at 12:37 PM, Mike Gilbert <flo...@gentoo.org> wrote:

This seems likely to cause problems for distros that build chromium
against system libs that are linked with libstdc++. Having both libc++
and libstdc++ loaded in the same process sounds dangerous.

The libc++ symbols will be private to chrome, so hopefully there should be no collisions.  The only thing explicitly exported is operator new/delete.

 

> email to chromium-packagers+unsub...@chromium.org.

[Nico Weber]

I don't think it is. libc++ uses an inline namespace to mangle all its symbols to something else so there aren't any symbol collisions, chrome already intercepts operator new, and we don't pass c++ objects out of or into chrome over library boundaries.

Are you thinking of concrete issues, or is this more a general "sounds risky"?

(FWIW, as mentioned in the doc, we did the same thing on macOS a while ago when we still supported macOS 10.6 where the system library was libstdc++ as well.)

> email to chromium-packagers+unsub...@chromium.org.

[Mike Gilbert]

It just sounded risky to me. It sounds like you have thought this
through though. We shall see what happens when this lands in the dev
channel. ;-)

>> > email to chromium-packag...@chromium.org.