llvm dev - Feb 2015 - [LLVMdev] [cfe-dev] [RFC] When can libc++ "officially" support linux?

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>

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/llvm-dev/attachments/20150220/831d0d6a/attachment.html>

On 21 Feb 2015, at 03:29, Chandler Carruth <chandlerc at google.com>
wrote:
> 
> 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++).
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

----- Original Message -----
> From: "Chandler Carruth" <chandlerc at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Eric Fiselier" <eric at efcs.ca>, "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>
> Sent: Friday, February 20, 2015 9:29:50 PM
> Subject: Re: [cfe-dev] [RFC] When can libc++ "officially" support
linux?
> 
> 
> 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 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
> 
> 
> 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.
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

----- Original Message -----
> From: "Chandler Carruth" <chandlerc at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Eric Fiselier" <eric at efcs.ca>, "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>
> Sent: Friday, February 20, 2015 9:29:50 PM
> Subject: Re: [cfe-dev] [RFC] When can libc++ "officially" support
linux?
> 
> 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++).
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
> 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.
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory