0

I created a DLL using MinGW 32 bit compiler using the __stdcall calling convention. Because DLL is used by a external tool requiring this calling convention without the @ notation I used the -Wl,--kill-at notation. The external tool operates successfully with my generated DLL. If I try to link a sample c application against this library I get linker errors caused by the incorrect calling convention.

These are the macros used in the interface header file.

#if defined(_WIN64)
    #define CALL_CONV            __fastcall
#elif (defined(WIN32) || defined(_WIN32) || defined(__WIN32__) || defined(__NT__)) && !defined(_NI_mswin16_)
    #define CALL_CONV            __stdcall
#endif

#ifdef IS_DLL_TARGET
    #undef _VI_FUNC
    #define _VI_FUNC  __declspec(dllexport) CALL_CONV
#elif defined BUILDING_DEBUG_EXE
    #undef _VI_FUNC
    #define _VI_FUNC
#else
    #undef _VI_FUNC
    #define _VI_FUNC  __declspec(dllimport) CALL_CONV
#endif

The linker complaints about

../main.c:343: undefined reference to `_imp__findRsrc@8'

What seams correct because I removed the @. I already tried using the -Wl,--kill-at flag when linking against the library unsuccessfully. What do I have to modify to successfully link against my modified __stdcall library.

One strange thing I discovered the @notation is still present in the .def file. My .lib and .dll file contains only names without the @.

Edit:

I found a work around but still the build progress is quite complicated and difficult to automate.

gcc -o AddLib.dll add.o -shared -s -Wl,--subsystem,windows,--output-def,AddLib.def
gcc -o AddLib.dll add.o -shared -s -Wl,--subsystem,windows,--kill-at
dlltool --kill-at -d AddLib.def -D AddLib.dll -l libaddlib.a
Jonny Schubert
  • 1,393
  • 2
  • 18
  • 39
  • I discovered that the created import lib by gcc using the -Wl,--kill-at is somehow still containing the @ notation information. If using the dlltool.exe I managed to create a correct and working import lib. Is there any way to create a correct import lib without using the additional tool and two different linker invocations. – Jonny Schubert Mar 08 '18 at 13:28
  • Sorry I'm not sure if I understand you correctly. I did not create the def file by my self. I told the gcc linker to generate the .def file. This generated file should not miss a function. I don't hate the @ feature at all. The circumstances with the external tool force me to alter the name mangling. – Jonny Schubert Mar 08 '18 at 13:38
  • See this [question](https://stackoverflow.com/questions/4550294/stdcall-name-mangling-using-extern-c-and-dllexport-vs-module-definitions-msvc). Try wrapping the function declarations in `extern "C"` to eliminate the "@" in the .def file. – Mark Benningfield Mar 08 '18 at 15:22

0 Answers0