Cозданиe DLL для Windows с помощью MinGW

Question

[zeksa]

Пытаюсь создать простенькое приложение на COM, всё сделал по учебнику.
Программирую в Netbeans с помощью MinGW. И клиент, и собственно сервер(dll) отлично компилятся. После неких мук с __stdcall, __cdecl и .def файлами удалось даже зарегестрировать dll в реестре. Собирал тот же код в VS2008, всё тоже компилится, регестрируется и даже корректно работает.
Сначала проверил дамп экспортируемых функций с помощью objdump — всё ок. Потом с помощью инструмента gendef автоматически генерировал .def файл для созданной dll. Вышло вот такое:

LIBRARY "libCOMdll2.dll"
EXPORTS
CLSID_Component2 DATA
DllCanUnloadNow
DllGetClassObject@8
DllMain@12
DllRegisterServer
DllUnregisterServer

Сначала думал что проблема в постфиксах,

"@"

причём один из них стоит после имени DllMain, откуда dll начинает свою работу. После генерации .def файла с другой dll, сделанной в VS, получил точно такой же результат — но ведь всё работает!
В VS в настройках проэкта увидел что в настройках calling convention стоит __cdecl, но всё равно функции используют свои вызовы.
Подскажите, пожалуйста, как корректно скомпилировать dll в MinGW. Буду рад помощи.

Comments

[yeputons]

А в чём, собственно, проблема?
Не находит функции, не создаётся DLL?

[zeksa]

Warning: resolving _DllCanUnloadNow by linking to _DllCanUnloadNow@0
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Warning: resolving _DllGetClassObject by linking to _DllGetClassObject@12
Warning: resolving _DllMain by linking to _DllMain@12
Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0
Warning: resolving _DllUnregisterServer by linking to _DllUnregisterServer@0

При компиляции выдаёт такие предупреждения. Одно из них:

Warning: resolving _DllGetClassObject by linking to _DllGetClassObject@12

Если посмотреть выше на сгенерированный .def, компилятор не везде обрезает "@" в именах функций.
VisualStudio делает так же.
Ещё один интересный факт: компилятор выдаёт предупреждение,

Warning: resolving _DllGetClassObject by linking to _DllGetClassObject@12

а потом в сгенерированном .def файле получаем

DllGetClassObject@8

. Тобишь где-то и как-то изменяется постфикс из 12 на 8.
В .def файлах, сгенерированных из VS dll, постфикс после DllGetClassObject стоит как 12

[zeksa]

удалось полностью убрать какие-либо дописи к именам всех функций.
dll не работает и не регестрируется в реестре.

[zeksa]

При проверке dll майкрософтовским dumpbin:

Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file ./libCOMdll2.dll

File Type: DLL

  Section contains the following exports for libCOMdll2.dll

    00000000 characteristics
    50A8C0E3 time date stamp Sun Nov 18 13:05:07 2012
        0.00 version
           1 ordinal base
           6 number of functions
           6 number of names

    ordinal hint RVA      name

          1    0 00004164 CLSID_Component2
          2    1 00002380 DllCanUnloadNow
          3    2 00001BB6 DllGetClassObject
          4    3 00002388 DllMain
          5    4 00002390 DllRegisterServer
          6    5 00002398 DllUnregisterServer

  Summary

        1000 .CRT
        1000 .bss
        1000 .data
        1000 .debug_abbrev
        1000 .debug_aranges
        1000 .debug_frame
        6000 .debug_info
        1000 .debug_line
        2000 .debug_loc
        1000 .debug_pubnames
        1000 .debug_pubtypes
        1000 .debug_ranges
        1000 .debug_str
        1000 .edata
        1000 .eh_frame
        1000 .idata
        1000 .rdata
        1000 .reloc
        2000 .text
        1000 .tls
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file ./DLL.dll

File Type: DLL

  Section contains the following exports for DLL.dll

    00000000 characteristics
    50A7F135 time date stamp Sat Nov 17 22:19:01 2012
        0.00 version
           1 ordinal base
           6 number of functions
           6 number of names

    ordinal hint RVA      name

          1    0 00018824 CLSID_Component2 = _CLSID_Component2
          2    1 000111C7 DllCanUnloadNow = @ILT+450(_DllCanUnloadNow@0)
          3    2 0001134D DllGetClassObject = @ILT+840(_DllGetClassObject@12)
          4    3 00011069 DllMain = @ILT+100(_DllMain@12)
          5    4 00011334 DllRegisterServer = @ILT+815(_DllRegisterServer@0)
          6    5 00011005 DllUnregisterServer = @ILT+0(_DllUnregisterServer@0)

  Summary

        1000 .data
        2000 .idata
        3000 .rdata
        1000 .reloc
        1000 .rsrc
        7000 .text
       10000 .textbss

что зачит

2    1 000111C7 DllCanUnloadNow = @ILT+450(_DllCanUnloadNow@0)

?

Answer 1

[zeksa]

Созданный на MinGW клиент не может подсоединиться к dll.
Причём коннектится к дллке, созданной на VisualStudio. Тобишь клиент работает корректно.
Просто сильно хочется разобраться, в чём «собака зарыта».

Answer 2

[Veliant]

GNU ld has many options regarding DLLs, but we shall only focus on four (help information follows):
--add-stdcall-alias Export symbols with and without @nn
--kill-at Remove @nn from exported symbols
--out-implib Generate import library
--output-def Generate a .DEF file for the built DLL

Comments

[zeksa]

Пробовал делать так же.
Ничего не изменилось, вопрос уточнил выше.

Answer 3

[OCTAGRAM]

Кроме __cdecl, возможно, надо оборачивать прототипы в extern «C» { }

Comments

[zeksa]

спасибо, но это тоже пробовал.
Думаю с __cdecl было бы меньше проблем, но прототипы в WinApi исользуют _stdcall
extern «C» не помогло

Answer 4

[MikhailEdoshin]

Насколько я понимаю, суффиксы @8 и т. п. добавляются к функциям, для которых указан формат вызовов stdcall и означают размер стека. Это зависит от компилятора вообще-то, но и MSVC, и mingw тут совпадают. Если такую функцию предполагается экспортировать из получившейся DLL, дополнительно создается алиас без суффикса, что мы, собственно, тут и видим:

DllCanUnloadNow = @ILT+450(_DllCanUnloadNow@0)

Мне не нравится различие в DllMain — @8 и @12, правильное, судя по спецификации, @12 — передаются три указателя, но тут один куда-то девается. У вас DllMain точно три параметра принимает?

Comments

[MikhailEdoshin]

То есть не DllMain, а DllGetClassObject, но смысл вопроса тот же.

[zeksa]

спасибо за помощь
да, принимается три параметра и в DllMain, и в DllGetClassObject
причём gendef из пакета MinGW показывает что два, тобишь додаёт «8», а dumpbin из VS указывает имена функций без каких-либо фокусов

[MikhailEdoshin]

gendef он ведь из dll-ки создает def-файл? А если ему работающую DLL скормить от MSVC, он там тоже @8 показывает?

Answer 5

[zeksa]

нет, показывает @12 после DllMain и @12 после DllGetClassObject

Comments

[MikhailEdoshin]

А вы не пробовали определить, на каком этапе он не может подсоединиться? На этапе собственно загрузки библиотеки или же позже, на одном из вызовов?

[zeksa]

Скорее всего на этапе загрузки библиотеки клиентом