[cfe-dev] [libc++] Standard types on Windows declared dllimport, no definitions compiled

[Janus Lynggaard Thorborg via cfe-dev]

Hello,

I'm scavenging parts of libc++ as a standard library for some C++ jitting
using clang+llvm ORC.

I precompile the required sources of libc++ plus my runtimes, emitting that
as LLVM IR. The C++ "script" gets compiled as another translation unit, and
they are added as two llvm::Modules into a IRCompileLayer. Thus, I don't
link to any system runtimes.

Some types from libc++ create issues though, like std::string. I get
unresolved externals for member functions like string::data() and the
destructor. Looking at the IR dump of the user translation unit, functions
like string::data are only declared, and marked dllimport (and compiling
the libc++ source doesn't emit the definitions, either).

Any idea what gives? I looked at the attributes attached to
std::basic_string, which seems to be a mixture of _LIBCPP_INLINE_VISIBILITY
for the member functions, _LIBCPP_TEMPLATE_VIS on the class itself, and
_LIBCPP_EXTERN_TEMPLATE + _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS on the common
base class. I guess a mixture of these ends up defining the import/export
traits of std types in libc++, but I don't really know how to control them,
so I was hoping someone could give some quick pointers.

In my case,  _LIBCPP_INLINE_VISIBILITY  equals the always_inline attribute,
so why clang would emit dllimports for inline visible methods and not just
inline them I don't know, I'm starting to think types contained inside
libc++ system headers are treated in a special way depending on flags I
don't know.

Again, any hints would be appreciated :)

Regards, Janus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180223/5fe354fc/attachment.html>