[cfe-dev] [RFC][libcxx] Fixing "-stdlib=libc++ -lc++abi" on Linux -- Exporting libc++abi through libc++.so.

[Eric Fiselier via cfe-dev]

Hi Renato,

> Do you mean only libsupc++ or the whole libstdc++?

I think David meant that by default, libsupc++ is only provided by way of
libstdc++.so and we can't control that. For that reason it's best to link
against the whole libstdc++.so so we can get libsupc++.

> Erik's proposal will break if it includes either libsupc++ or libc++abi.

I'm a bit confused. My proposal can deal with both libsupc++ and libc++abi.
Could you elaborate on the issues you see?

On Wed, Oct 14, 2015 at 4:36 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 12 October 2015 at 12:19, David Chisnall via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > If you can not modify the linkage of libstdc++ on your target platform,
> then the best solution is to use libstdc++ itself as the ABI library.
>
> Do you mean only libsupc++ or the whole libstdc++?
>
> Back to Erik's proposal, the clang driver had some similar logic to
> Compiler-RT that was added and removed by me given the solutions and
> complications I found.
>
> From compiler-rt, on GNU systems, I added libgcc_s or libgcc_eh
> automatically, so one could use "--rtlib=compiler-rt" and get
> everything working out of the box. But that breaks out when you want
> to use libunwind, in the exact same way Erik's proposal will break if
> it includes either libsupc++ or libc++abi.
>
> Not controlling the base architecture is a problem, given that all
> your dynamic objects already link and use whatever the platform gives
> you. This takes us back to the drawing board.
>
> What do we want from our high level libraries?
>
> * Independent, good quality libraries? In which case testing
> compatibility with other base libraries is unnecessary and all we test
> are statically linked (or controlled dynamically linked) environments.
>
> * Inter-operational, sometimes redundant libraries? In which case we
> assume the target always has libgcc / libsupc++ and only ever replace
> compiler-rt and libc++, not the other two.
>
> I believe both solutions have huge problems, but I can't see the few
> of us actually supporting *well* both use cases at the same time.
>
> Ideas?
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151014/67d4e023/attachment.html>