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

[Shoaib Meenai via libcxx-dev]

Note that stdlib_exception.cpp and stdlib_new_delete.cpp already define _LIBCPP_BUILDING_LIBRARY. Perhaps stdlib_typeinfo.cpp should follow suit?

On 1/9/19, 2:36 PM, "libcxx-dev on behalf of Martin Storsjö via libcxx-dev" <libcxx-dev-bounces at lists.llvm.org on behalf of libcxx-dev at lists.llvm.org> wrote:

    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
    
    _______________________________________________
    libcxx-dev mailing list
    libcxx-dev at lists.llvm.org
    https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_libcxx-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=D0bERL6MLYNim22egPxtjGbQmMQIajQZOXY-c8oTaPw&s=OKZni8_Dn1vojVgOHGMojZWwbVlWsiDHB4lkYrPPPsQ&e=