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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

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

James Gregurich via cfe-dev

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

cfe-dev mailing list
[hidden email]