[cfe-dev] Porting libcxxabi / Unwind to Windows / MingW 32 bit

[Yaron Keren]

libstdc++ and libsupc++ are merged on MingW Windows distributions, I
assumed it's the default structure of gcc libs. Where it's not so it would
indeed make no sense to merge them.
It's best to follow  the existing conventions to make it easier for the
users replacing the libs.

Yaron



2013/11/2 David Chisnall <David.Chisnall at cl.cam.ac.uk>

> On 2 Nov 2013, at 12:27, Yaron Keren <yaron.keren at gmail.com> wrote:
>
> > Hi David,
> >
> > It's a good idea to have compiler-rt + unwind project in one project as
> a libgcc replacement. We can name the project "libclang".
>
> THe libclang name is already taken, but so is libcompiler_rt for this
> purpose...
>
> > While at it, the rest of libcxxabi (the _cxa functions) may be merged
> into libcxx as a complete replacement for libstdc++.
>
> We already ship the combination of libc++ and libcxxrt on FreeBSD as a
> complete replacement for libstdc++.
>
> > This project structure matches the gcc library organization and thus
> will be easier for people (and toolchains) to use them.
>
> Actually, the gcc structure has libstdc++ and libsupc++ as separate
> libraries.  On FreeBSD, we shipped them as separate dynamic libraries in
> 9.x so that you can stick libcxxrt under libstdc++ and mix code that uses
> libc++ and libstdc++.  OS X did something similar.  This setup allows
> people to use a newer libstdc++ (which we don't ship in the base system,
> but which you can get from ports) in a library used by an application that
> uses libc++, without causing errors (unless STL symbols are used on library
> interfaces).
>
> Merging libc++ and libc++abi would require anyone downstream who cared
> about interoperability to go and unmerge them again.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131102/643a5547/attachment.html>