<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">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" 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" 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" 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>
_______________________________________________<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></div>
</blockquote></div>