[libcxx-commits] [PATCH] D128927: [libc++] Always build c++experimental.a

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added a comment.

In D128927#3638973 <https://reviews.llvm.org/D128927#3638973>, @ldionne wrote:

> Thanks @mstorsjo! Regarding `_LIBCPP_EXPERIMENTAL_FUNC_VIS`, yes I think it would make sense to use a different visibility macro for symbols that we know are provided only as part of a static library. I would not call it `_LIBCPP_EXPERIMENTAL_FUNC_VIS` though, I would call it something like `_LIBCPP_STATIC_LIBRARY_FUNC_VIS` or something like that.

Sure, `_LIBCPP_STATIC_LIBRARY_FUNC_VIS` sounds good to me too.



================
Comment at: libcxx/utils/libcxx/test/params.py:68
+  if hasCompileFlag(cfg, '-funstable') and False: # TODO: Enable this once the design of `-funstable` is finished
+    return '-funstable'
+  else:
----------------
ldionne wrote:
> mstorsjo wrote:
> > Actually, I'm not entirely convinced that this is a good way to handle linking against the library for tests.
> > 
> > When building tests, we don't rely on the compiler to implicitly link in our C++ library, but we link with `-nostdlib++` (or `-nodefaultlibs`) and explicitly tell the compiler how to link in specifically the C++ library we've just built (in the test config files).
> > 
> > So in general, if linking with `-nostdlib++ -fexperimental-library` I kinda wouldn't expect the compiler driver to link against the library at all? It's kinda the same as if you'd do `-stdlib=libstdc++ -fexperimental-library` - we can't have that add `-lc++experimental`, as that only makes sense as long as we have `-stdlib=libc++`. So subsequently I don't think the compiler driver should be adding `-lc++experimental` as long as we're passing `-nostdlib++` either?
> > 
> > But if libc++experimental is built unconditionally, wouldn't it be simplest to just always link against it in the test config files (just like how we force it to link against specifically the just-built libc++.a) - that would make it much more symmetrcial to how we handle the main `-lc++`?
> Interesting point. It does mean that we can never rely on `-funstable` adding `-lc++experimental` from our test suite -- I think that's OK.
> 
> However, I'd like to avoid linking against `-lc++experimental` in the base test configuration, simply because the base test configuration should mirror the minimal way of invoking Clang to use libc++.
Yep. Also another example of why we can't really rely on the compiler driver adding it - technically I guess the compiler driver might even choose not to pass a generic `-lc++` or `-lc++experimental`, but pass an absolute path to the `libc++.{a,so,dylib}` that is bundled with the compiler (clang does this for compiler-rt builtins) - so we really do need to rely on `-nodefaultlibs` and/or `-nostdlib++` omitting the compiler-provided defaults.

Keeping adding `-lc++experimental` here instead of adding it in the base config files is fine with me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128927/new/

https://reviews.llvm.org/D128927