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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
