0

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 ?

DaveC
  • 115
  • 8
  • Why gcc 6.3.0? That's a version from 2016, current gcc version is 11.2.0. Also current MinGW-w64 version is 9.0.0. – Brecht Sanders Feb 12 '22 at 13:01
  • Well the industry is sometimes a bit slow to adopt new tools and often prefers (for better or worse) old and trusted ways... Most tools I work with only support (officially at least) gcc 6.3.0 (e.g. [matlab 2020a](https://www.mathworks.com/content/dam/mathworks/mathworks-dot-com/support/sysreq/files/system-requirements-release-2020a-supported-compilers.pdf) or hardware simulation tools from Cadence and Synopsys). As I said, I know to avoid the issue, but I'm trying to learn: are my expectations incorrect, is there something in the linking strategy that I don't understand ? or just a bug ? – DaveC Feb 12 '22 at 17:04
  • I don't know why your libraries export standard library functions. Have you tried ignoring the issue by linking with `-Wl,--allow-multiple-definition` ? – Brecht Sanders Feb 12 '22 at 17:11
  • I didn't try that but I'm quite sure it would avoid the issue. As I said, my question is not how to avoid the issue though, but why it's happening. Is there a bug in MinGW-w64 8.0.0 and/or in gcc 6.3.0 ? Has this bug been clearly identified and explicitly fixed ? or is it still there in MinGW-w64 9.0.0 and/or in gcc 11.2.0 ? – DaveC Feb 14 '22 at 19:14

0 Answers0