[RFC] When can libc++ "officially" support linux?

Project Infrastructure LLVM Dev List Archives
1

Hi All,

Currently libc++ does not list linux as a supported platform. This
should change. I think we should be able to list linux (with
libc++abi) as a supported configuration. but there are some issues I
would like to see resolved first.

1. We should add CMake support for building libc++ against a static
libc++abi. If libc++ is linked to a shared libc++abi the resulting
library can only be used when libc++abi is manually linked by the
user. We should strongly prefer building libc++ against a static
libc++abi on linux.

2. We need to clarify how libstdc++ and libsupc++ can be used as
libc++'s ABI library and explicitly define the level of support for
these configurations. Are there any people using this functionality?
These configurations have been broken for GCC >= 4.9.2 and I haven't
heard any complaints. I would like to drop these configurations all
together.

3. Tests should be added that verify the exception types in libc++ and
libstdc++ are ABI compatible and can be thrown between libraries.

Is there anything else that needs to be done before libc++
"officially" supports linux?

/Eric

2

From: "Eric Fiselier" <eric@efcs.ca>
To: "cfe-dev@cs.uiuc.edu Developers" <cfe-dev@cs.uiuc.edu>, "LLVM Dev" <llvmdev@cs.uiuc.edu>, "Marshall Clow"
<mclow.lists@gmail.com>, "Dan Albert" <danalbert@google.com>, "Chandler Carruth" <chandlerc@google.com>
Sent: Friday, February 20, 2015 8:48:18 PM
Subject: [cfe-dev] [RFC] When can libc++ "officially" support linux?

Hi All,

Currently libc++ does not list linux as a supported platform. This
should change. I think we should be able to list linux (with
libc++abi) as a supported configuration. but there are some issues I
would like to see resolved first.

1. We should add CMake support for building libc++ against a static
libc++abi. If libc++ is linked to a shared libc++abi the resulting
library can only be used when libc++abi is manually linked by the
user. We should strongly prefer building libc++ against a static
libc++abi on linux.

2. We need to clarify how libstdc++ and libsupc++ can be used as
libc++'s ABI library and explicitly define the level of support for
these configurations. Are there any people using this functionality?
These configurations have been broken for GCC >= 4.9.2 and I haven't
heard any complaints. I would like to drop these configurations all
together.

I'm currently using the configuration where libc++ builds on top of libstdc++ (specifically, the version from GCC 4.7.2). I have vendor-provided static libraries that I need to link against (although only use via a C API) that were compiled against libstdc++. Please don't drop that configuration.

Thanks again,
Hal

3

+1

4

So, I at least misread this, and maybe you did as well Hal.

I think what needs to work is allowing a binary library to be linked into
an application built with libc++ while that library uses libstdc++.

Eric pointed out to me that this doesn't actually require building libc++
"on top of" libstdc++. libc++abi and libsupc++ are supposed to be
ABI-compatible. It should be possible to use libc++, libc++abi, and
libstdc++ (without libsupc++). This is the use case I personally have and I
think it is likely the primary use case people will have on linux. There
shouldn't be any technical reason to need to use libsupc++ for the ABI
components, whether bundled inside libstdc++ or on its own. Hal, do you
actually need that configuration?

If no one needs libsupc++ specifically, then I think it would be fine to
rely completely on libc++ and libc++abi going together on Linux as long as
we routinely test that linking libstdc++ into the mix continues to work and
can correctly use libc++abi's implementation bits.

5

Kind of. If you link both in and different libraries see the common symbols from both then you are going to see some very odd things happen when you throw exceptions - the EH code in both refers to static variables and will become very confused.

The default configuration for libstdc++ statically links libsupc++. This was the first thing that we had to change on FreeBSD to allow using both libraries, as our libstdc++ lacked some symbols from libcxxrt that libc++ needed. If you need to work with a vendor-provided libstdc++, then you will probably need to make libc++ use its libsupc++ implementation.

We now support linking both libc++ and libstdc++ into the same binary, but only with libcxxrt (libc++abi would also work, as long as you're willing to give up EH interop with other languages and break anything else that relies on type_info vtable layout).

David

6

From: "Chandler Carruth" <chandlerc@google.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "Eric Fiselier" <eric@efcs.ca>, "cfe-dev@cs.uiuc.edu Developers" <cfe-dev@cs.uiuc.edu>, "LLVM Dev"
<llvmdev@cs.uiuc.edu>, "Marshall Clow" <mclow.lists@gmail.com>, "Dan Albert" <danalbert@google.com>
Sent: Friday, February 20, 2015 9:29:50 PM
Subject: Re: [cfe-dev] [RFC] When can libc++ "officially" support linux?

> 2. We need to clarify how libstdc++ and libsupc++ can be used as
> libc++'s ABI library and explicitly define the level of support for
> these configurations. Are there any people using this
> functionality?
> These configurations have been broken for GCC >= 4.9.2 and I
> haven't
> heard any complaints. I would like to drop these configurations all
> together.

I'm currently using the configuration where libc++ builds on top of
libstdc++ (specifically, the version from GCC 4.7.2). I have
vendor-provided static libraries that I need to link against
(although only use via a C API) that were compiled against
libstdc++. Please don't drop that configuration.
+1
So, I at least misread this, and maybe you did as well Hal.

I didn't; that's really the configuration I use.

I think what needs to work is allowing a binary library to be linked
into an application built with libc++ while that library uses
libstdc++.

Eric pointed out to me that this doesn't actually require building
libc++ "on top of" libstdc++. libc++abi and libsupc++ are supposed
to be ABI-compatible. It should be possible to use libc++,
libc++abi, and libstdc++ (without libsupc++). This is the use case I
personally have and I think it is likely the primary use case people
will have on linux. There shouldn't be any technical reason to need
to use libsupc++ for the ABI components, whether bundled inside
libstdc++ or on its own. Hal, do you actually need that
configuration?

To be fair, as I discussed briefly with Eric on IRC, I've been using the libc++ over libstdc++ configuration for a long time (longer than has been officially supported; I had my own hacked-together patch at one point), and I've not experimented with this recently.

However, I'm also not entirely sure it is true that I can link to libstdc++ without getting libsupc++. I don't believe that we link separately to libsupc++, but rather, libsupc++.a is actually a part of libstdc++.a (they define an overlapping set of symbols). This seems easy enough to work around for static linking, but I recall that this will cause problems for dynamic linking.

I'll experiment this week and see if I can make libc++abi work.

Thanks again,
Hal

7

From: "Chandler Carruth" <chandlerc@google.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "Eric Fiselier" <eric@efcs.ca>, "cfe-dev@cs.uiuc.edu Developers" <cfe-dev@cs.uiuc.edu>, "LLVM Dev"
<llvmdev@cs.uiuc.edu>, "Marshall Clow" <mclow.lists@gmail.com>, "Dan Albert" <danalbert@google.com>
Sent: Friday, February 20, 2015 9:29:50 PM
Subject: Re: [cfe-dev] [RFC] When can libc++ "officially" support linux?

> 2. We need to clarify how libstdc++ and libsupc++ can be used as
> libc++'s ABI library and explicitly define the level of support for
> these configurations. Are there any people using this
> functionality?
> These configurations have been broken for GCC >= 4.9.2 and I
> haven't
> heard any complaints. I would like to drop these configurations all
> together.

I'm currently using the configuration where libc++ builds on top of
libstdc++ (specifically, the version from GCC 4.7.2). I have
vendor-provided static libraries that I need to link against
(although only use via a C API) that were compiled against
libstdc++. Please don't drop that configuration.
+1
So, I at least misread this, and maybe you did as well Hal.

I think what needs to work is allowing a binary library to be linked
into an application built with libc++ while that library uses
libstdc++.

Eric pointed out to me that this doesn't actually require building
libc++ "on top of" libstdc++. libc++abi and libsupc++ are supposed
to be ABI-compatible. It should be possible to use libc++,
libc++abi, and libstdc++ (without libsupc++).

Okay, I think this is the point of misunderstanding here. How do you use libstdc++ without libsupc++? On my system, while I do have a separate libsupc++.a, the contents of that archive are also included in libstdc++.a. This is true both on my BG/Q toolchains (using GCC 4.7.2), and also on a Fedora 19 system (using GCC 4.8.3) I just checked.

Thanks again,
Hal