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

[Maarten Verhage via libcxx-dev]

Hi Martin and others,

Remember I was trying to get shared LLVM libraries: libc++abi and libc++ to 
build with the mingw64 GCC compiler on Windows. The goal is to have separate 
libc++dll and libc++abi.dll files.

I'm working on a Python script that generate a single mingw makefile that 
can build both libraires. I'll show it when it's finished. I believe the 
finish is near. Please see further below.

>> 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))".
>

Yeah, I learned that both: __declspec(dllexport) and 
__attribute__((dllexport)) will do.

>> 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?
>

To answer my own question: The low libc++abi.dll size was due a missing 
linker option:
-Wl,--whole-archive cxx_objects.a -Wl,--no-whole-archive

> 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.)

As libc++ and libc++abi sources are quite large. I first setup a little 
example with two dlls that use functions of each. In that makefile I first 
build two import libraries for each dll with dlltool and later linking the 
object code against the import library of the other dll. No problems.

Regarding the circular dependencies I believe a link commands such as:
-Wl,--start-group <multiple circular dependency libs> -Wl,--end-group
is the proper way to ask gcc to figure this out.

Something on SO about this:
https://stackoverflow.com/questions/9380363/resolving-circular-dependencies-by-linking-the-same-library-twice

> 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

I hope to get it a little better than -Wl,--export-all-symbols.

Ok, please read with me, I try to be as clear as I could:
What I'm facing right now. The shared library build of libc++abi needs to 
process the import library: libc++.dll.a. But the linker gives undefined 
references to things like __imp__ZNSt8bad_castC1Ev. When I run the nm tool 
on the archive libary cxx_objects.a I see symbols like these are all 
available. But I believe when I run the dlltool to make the import libary 
from cxx_objects.a I loose the visibility of the symbols (exported stuff). 
In the libcxx source folder in the subdirectory lib there are exp files that 
contain symbols for exports which needs to be applied somehow to the build 
of libc++. The file libc++abi2.exp contain the exports which I believe I 
would need. The symbol names match. In the build of libc++ in the cmake 
style they seem to do it on the final linking stage with options 
like -Wl,-reexported_symbols_list,<.exp file>.
I my situation it seems to make more sense to apply these symbols to the 
creation of the import library. But I cannot figure out with GNU binutil 
tool I should use for this and what options to use. I know I can do 
an --input-def option on the call to dlltool. But that libc++abi2.exp is not 
a Windows def file. So, I do need a little help with this.

Best regards,
Maarten Verhage