llvm dev - Feb 2015 - [LLVMdev] [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.

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

----- Original Message -----
> From: "Eric Fiselier" <eric at efcs.ca>
> To: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at
cs.uiuc.edu>, "LLVM Dev" <llvmdev at cs.uiuc.edu>,
"Marshall Clow"
> <mclow.lists at gmail.com>, "Dan Albert" <danalbert at
google.com>, "Chandler Carruth" <chandlerc at 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. 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150220/bfa9954d/attachment.html>