[libcxx-dev] build issue on mingw gcc, need some help

Martin Storsjö via libcxx-dev libcxx-dev at lists.llvm.org
Fri Dec 28 12:08:58 PST 2018


Hi,

On Fri, 28 Dec 2018, Maarten Verhage via libcxx-dev wrote:

> I started to make a straightforward mingw64 makefile to build the shared
> version of libc++abi. As I'm on Windows I believe _LIBCXXABI_FUNC_VIS should
> end up being __declspec(dllexport) but when I do a preprocess only on a file
> like cxa_personality.cpp I see _LIBCXXABI_FUNC_VIS end up being
> __attribute__((dllexport)).

GCC actually only supports the latter. The former is expanded into the 
latter by the preprocessor; if you dump the default defines by "gcc -E -dM 
- < /dev/null" (or similar with an empty normal input file)", you'll find 
"#define __declspec(x) __attribute__((x))".

> Somehow the file libc++abi.dll is build but it is just about 50 kB and 
> llvm-readobj -coff-exports shows nothing.
> 
> My question is what kind of define or flag might have caused this to happen?
> And how can I correct it?

First off, I haven't been able to build libc++abi standalone as a DLL, as 
there are some amount of circular dependencies between libc++abi and 
libc++. (If linking doesn't end up including everything, you might not 
notice this.)

Due to this, when building libc++ as a DLL, I build libc++abi as a static 
library, but manually override defines to get the same effect as if I had 
built libc++abi dynamically, and making the libc++ includes behave as if 
building libc++ itself, as the object files will be included within 
libc++.dll. Likewise, for libc++, I add defines to make libc++abi headers 
behave as if building libc++abi itself:

https://github.com/mstorsjo/llvm-mingw/blob/b9eb66bc/build-libcxx.sh#L143
https://github.com/mstorsjo/llvm-mingw/blob/b9eb66bc/build-libcxx.sh#L181

In the end, I top it off by linking the DLL with -Wl,--export-all-symbols. 
Without that, for me, a number of symbols aren't exported even if they are 
expected to. I believe that's a Clang-specific issue though, but I haven't 
analyzed it further yet, as this hack/workaround seems to work well enough 
for now.

// Martin



More information about the libcxx-dev mailing list