<div dir="ltr">Since we don't use the libc++ cmake build files and override the abi namespace (*), I think this wouldn't affect us.<div><br></div><div>*: We currently don't override the abi namespace on Windows, because there's no competing libc++ there. What's more, the natvis debugger integration file we use (<a href="https://cs.chromium.org/chromium/src/build/config/c%2B%2B/libc%2B%2B.natvis?q=file:%5C.natvis&sq=package:chromium&dr">https://cs.chromium.org/chromium/src/build/config/c%2B%2B/libc%2B%2B.natvis?q=file:%5C.natvis&sq=package:chromium&dr</a>) needs to mention the abi namespace name, so I suppose we'd have to explicitly set the abi namespace to __1 on Windows. Or we could change the natvis file to say __9000. There's a thread somewhere about upstreaming that file; we probably would want to have one natvis file per abi version (with "latest" being a version) anyway.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 23, 2019 at 6:31 AM Eric Fiselier via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org">libcxx-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I think that's the right approach. <div dir="auto"><br></div><div dir="auto">I'll change the namespace for unstable. Since the ABI is unstable I think the namespace should be as well. So I think I'll make it `__<version-number>`, so right now it would be __9000. (though that's a bit long).<div dir="auto"><br></div><div dir="auto">I'm less sure what to about the SO version number, but I'm also unfamiliar with how SO versioning is supposed to work </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat., Jun. 22, 2019, 9:44 p.m. Richard Smith via libcxx-dev, <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Maybe a better approach would be to ensure that the unstable-ABI libc++ has a different file name / soname version than the stable ABI library. Would that satisfy the needs of Chromium and Fuchsia?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 22 Jun 2019 at 16:55, Petr Hosek <<a href="mailto:phosek@chromium.org" rel="noreferrer" target="_blank">phosek@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>We cross-compile libc++ for Fuchsia as a shared library with LIBCXX_ABI_UNSTABLE in the CMake build so I'd prefer if this was overridable/optional.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 22, 2019 at 3:26 AM Nico Weber via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" rel="noreferrer" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">We depend on being able to build libc++ as a shared library with LIBCXX_ABI_UNSTABLE set in Chromium. We build libc++ from source as part of a regular chrome build, and in a component build (where each library of chrome becomes a .so) libc++ must be a .so as well.<div><br></div><div>(We use a custom inline namespace name, and we make sure our libc++ is always on the search path before system libc++).<br><div><br></div><div>We don't use libc++'s cmake files, so if this is just about libc++'s cmake setup, we don't have an opinion on this.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 22, 2019 at 12:42 AM Richard Smith via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" rel="noreferrer" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">By default, libc++ builds produce a shared library and a static library. When LIBCXX_ABI_UNSTABLE is enabled, though, that seems like a mistake: there is no stable interface, so dynamically linking against an unstable-ABI libc++ shared library will be problematic.<div><br></div><div>In addition, if LIBCXX_ABI_VERSION is not specified during configuration, the default behavior of the build system with LIBCXX_ABI_UNSTABLE enabled is to produce a libc++.so.1.0 with the unstable ABI, which causes problems if it's found on the library search path for a binary built against the normal-ABI libc++.so.1.0. (And in a stock monorepo build, this means that enabling LIBCXX_ABI_UNSTABLE and then building, say, llvm and libc++, with a host compiler that uses libc++ as the standard library, results in broken LLVM binaries in the build area: they were compiled against the stable libc++ ABI but will pick up an unstable-ABI version of libc++ at runtime.)</div><div><br></div><div>Perhaps we should refuse to build a shared library version of libc++ with the unstable ABI enabled?</div></div>
_______________________________________________<br>
libcxx-dev mailing list<br>
<a href="mailto:libcxx-dev@lists.llvm.org" rel="noreferrer" target="_blank">libcxx-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br>
</blockquote></div>
_______________________________________________<br>
libcxx-dev mailing list<br>
<a href="mailto:libcxx-dev@lists.llvm.org" rel="noreferrer" target="_blank">libcxx-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br>
</blockquote></div></div>
</blockquote></div>
_______________________________________________<br>
libcxx-dev mailing list<br>
<a href="mailto:libcxx-dev@lists.llvm.org" rel="noreferrer" target="_blank">libcxx-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br>
</blockquote></div>
_______________________________________________<br>
libcxx-dev mailing list<br>
<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br>
</blockquote></div>