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

Chandler Carruth chandlerc at google.com
Fri Feb 20 19:29:50 PST 2015


On Fri, Feb 20, 2015 at 7:11 PM, Chandler Carruth <chandlerc at google.com>
wrote:

> On Fri, Feb 20, 2015 at 7:02 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>> > 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++). 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150220/831d0d6a/attachment.html>


More information about the cfe-dev mailing list