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

[Martin Storsjö via libcxx-dev]

On Wed, 9 Jan 2019, Maarten Verhage wrote:

> Hi Martin and others,
>
> Sorry for my inaccurate description of the issues I'm facing. Rather than
> trying to address the topics of misunderstanding between us I thought it
> would be best to share what I currently have of the Python script and what
> my makefile writes to the command line.
>
> I put it all in the attachments. result.txt is the output of the makefile.
> Although it's a lot of text I believe it is as specific as can be and I hope
> it will be easy to navigate through. I'm certainly willing to explain what
> I'm trying to achieve if need to. And I do also take criticism on my script.
>
> The python script first would need some edits (in the beginning) to find the
> folders of libc++ and libc++abi sources on your harddisk.
>
> As per your suggestion I put the following section into __config file of the
> libcxx include folder:
>
> #  if defined(__MINGW32__)
> #    define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS _LIBCPP_DLL_VIS
> #    define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
> #  else
> #    define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
> #    define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS _LIBCPP_DLL_VIS
> #  endif
>
>
> But still undefined reference to __imp__ZNSt8bad_castC1Ev and more.

Yes, this is not supposed to help with this issue.

> I also edited libc++abi2.exp to make a valid def file and applied this to
> libc++. I believe it actually needs to be applied to libc++ and not
> libc++abi.
>
> Still the same undefined references.
>
> Please let me know where I got it wrong?

Ok, so the problem is this. The missing symbols, __imp__ZNSt8bad_castC1Ev, 
means that libc++abi tries to import the bad_cast class from another DLL. 
This class is declared in libc++ headers, and the libc++ visibility flags 
indicate that symbols declared there will be accessed as dllimport. But in 
this case, libc++abi itself provides the bad_cast class, even though it's 
declared by libc++ headers, not libc++abi headers.


ld.bfd doesn't seem to able to handle this situation, while ld.lld and 
link.exe can fix up such situations, with a minor warning, e.g. like this:

lld-link: warning: test.o: locally defined symbol imported: _Z4funcv 
(defined in test2.o) [LNK4217]

As a minimal example of this situation, I created two test cpp files. 
test.cpp:

void __declspec(dllimport) func(void);
void __declspec(dllexport) mainfunc(void) {
   func();
}

test2.cpp:

void __declspec(dllexport) func(void);
void func(void) {
}

When compiling and linking these files with GCC/ld.bfd, I get the 
following:

$ x86_64-w64-mingw32-g++ -c test.cpp
$ x86_64-w64-mingw32-g++ -c test2.cpp
$ x86_64-w64-mingw32-g++ test.o test2.o -o test.dll -shared
test.o:test.cpp:(.text+0xb): undefined reference to `__imp__Z4funcv'
collect2: error: ld returned 1 exit status

When linking with ld.lld instead, linking succeeds but with the warning I 
quoted above.



I don't have any good suggestion on how to proceed with this, other than 
building libc++ and libc++abi into one single DLL. While building 
libc++abi, it would need to include libc++ headers as if 
_LIBCPP_BUILDING_LIBRARY was set, but only for the declarations of those 
specific classes that are provided by libc++abi, nothing else.

Although, I'm not sure if there's much code in libc++abi that actually has 
undefined references to libc++ symbols, so in that case it might just work 
to define _LIBCPP_BUILDING_LIBRARY for all of the build of libc++abi. Or 
maybe just at the top of individual source files that provide the classes 
that are declared in libc++ headers.

// Martin