[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