CODEWITHSUNDEEP
mingw-w64mxe
DaveC
DaveC

Reputation: 167

Why would a cross-compiled DLL export symbols already defined in MSVCRT?

I'm using MXE to build my own cross-compiler toolchain (this specific version). Only I don't use the default gcc 5.5 but gcc 6.3.0 instead.

I'm not specifically tied to that version - I just picked it because it was also used to generate the latest portaudio binaries

It appears that for some reason, some MSVCRT symbols have been included in and are exported by the portaudio DLL:

dumpbin /exports libportaudio64bit.dll

    992  3DF 00032F30 mbrlen
    993  3E0 00032D90 mbrtowc
    994  3E1 00032E00 mbsrtowcs
   1112  457 00033180 wcrtomb
   1113  458 000331C0 wcsrtombs

I only found out because I was trying to cross-compile and build bzip2 1.0.8 This is pretty old and it doesn't have all the infrastructure in place to support cross-compiling. However it can be done by hand in a couple of very simple steps:

   make CC=x86_64-w64-mingw32.shared-gcc AR=x86_64-w64-mingw32.shared-ar RANLIB=x86_64-w64-mingw32.shared-ranlib libbz2.a 
   x86_64-w64-mingw32.shared-gcc *.o -s -shared -o libbz2-1.dll

Alike the portaudio DLLs, the above exports the same symbols:

dumpbin /exports libbz2-1.dll

     36   23 00012B60 mbrlen
     37   24 000129F0 mbrtowc
     38   25 00012A60 mbsrtowcs
     39   26 00012DC0 wcrtomb
     40   27 00012E00 wcsrtombs

Needless to say, this is causing issues at link time, due to multiple definitions of the same symbol (mingw-w64-v8.0.0/mingw-w64-crt/misc/mbrtowc.c:98: multiple definition of 'mbrtowc' - x86_64-w64-mingw32.shared/lib/../lib/libmsvcrt.a(lib64_libmsvcrt_os_a-mbrtowc.o): first defined here)

My question is not how to avoid this issue. That can be done by using a DEF file when building the DLLs, to control the exact list of exported functions.

My question is more fundamental: why would these symbols be exported in the first place ? Is this a bug somewhere ?

Upvotes: 0

Views: 142

Answers (0)

Related Questions