MinGW and export link libs

[John E]

My original question was posted on the VC++ forum but it's become clear that this is a MinGW issue.

To cut a long story short, I'm building an app using VC++. The app links to a DLL built using TDM-GCC (which uses MinGW I think). Obviously, the DLL comes with a link lib.

If the lib is linked to another MinGW app, the DLL functions get found by name. So if the DLL builder updates his DLL, the MinGW app carries on working.

However, if the same lib is linked to a VC++ app, the functions get found by ordinal value. But MinGW doesn't seem to have any means of guaranteeing that a later build of the DLL will use the same numbering scheme. So his new DLL will break the pre-existing VC++ app that used it.

In VC++ this problem could be solved by using a DEF file but that doesn't seem to work in MinGW. So my question is:- can a DLL built with MinGW be somehow instructed to export its functions only by name - or at least to export them so that any other compiler will import them by name and not by ordinal numbers?

[Codeplug]

>> So his new DLL will break the pre-existing VC++ app that used it.
If you are linking with the current .lib that goes with that DLL, then you shouldn't have a problem.

If you are using an old .lib for the new DLL, that can be a problem.

Are you saying that the new .lib for the new .DLL doesn't work with MSVC?

gg

[John E]

Are you saying that the new .lib for the new .DLL doesn't work with MSVC?

Not quite, Codeplug. If he brings out a new DLL, we need to rebuild our app. In most cases, this shouldn't really be necessary as his public interface rarely changes. What's changing are the ordinal numbers assigned to his exported functions.

We've found a temporary solution.... I can build his DLL with MSVC, then throw away my (MSVC built) DLL and use his (MinGW built) one. My MSVC built link lib forces our app to import the symbols from his DLL by name instead of by ordinal number. In that way, our app continues to run just fine, even if he updates his DLL (we've tried it).

It would be more logical though if we could obtain a solution from MinGW.

[Codeplug]

>> If he brings out a new DLL, we need to rebuild our app.
Ok, so your goal to take on new 3rd party DLL's without having to re-link.

>> We've found a temporary solution...
>> My MSVC built link lib forces our app...
If your goal is not to re-link, then I wouldn't call a re-link a "temporary solution". The immediate "solution" is to just re-link with the new .lib that goes with the new .dll.

How are the .lib's generated on the MinGW side? I would like to try and reproduce the issue.

gg

[John E]

I think you've misunderstood, Codeplug.

I only need to link our app once (to the link lib that I built using MSVC). From then on, our supplier can update his DLL whenever he likes without us needing to do anything (this is possible because his public interface is very unchanging).

OTOH if we use his (MinGW built) link lib then, most times when he builds a new DLL, we need to obtain the new link lib and rebuild (which we don't want to do).

How are the .lib's generated on the MinGW side? I would like to try and reproduce the issue.

I don't use MinGW so I can't answer your question but I can explain how to reproduce it.... Build a DLL using MinGW then create an app in MSVC which links to the (MinGW built) link lib. Now open the app in Dependency Walker. Note that all functions from the DLL are being imported by ordinal value, not by name. Therefore if the ordinal enumeration changes when he builds his next DLL (which it will, if he adds a new function) the new DLL can no longer be used without rebuilding the app.

[Codeplug]

The thing is, MinGW does not produce .lib files. Typically only MS tools create those.

So "how" they are creating the .lib seems to be the problem.

Here's how I would do it:

C:\MinGW-Projects\gg>type TADll.h
// TADll.h
#ifndef DLL_H
#define DLL_H

#if defined(BUILDING_DLL)
#   define DLL_API __declspec(dllexport)
#else
#   define DLL_API __declspec(dllimport)
#endif

#ifdef __cplusplus
extern "C" {
#endif

DLL_API int __stdcall foo();
DLL_API int __stdcall bar();

#ifdef __cplusplus
}/* extern "C" */
#endif

#endif //TA_DLL_H

C:\MinGW-Projects\gg>type TADll.cpp
// TADll.cpp
#include <windows.h>

#include "TADll.h"
#include <iostream>
using namespace std;

DLL_API int __stdcall foo()
{
    cout << "foo" << endl;
    return 1;
}

DLL_API int __stdcall bar()
{
    cout << "bar" << endl;
    return 1;
}

C:\MinGW-Projects\gg>g++ -DBUILDING_DLL -shared -I. -L. -Wl,--out-implib,libTADl
l.a,--output-def,TADll.def TADll.cpp
Creating library file: libTADll.a

C:\MinGW-Projects\gg>type TADll.def
EXPORTS
    bar@0 @1
    foo@0 @2

C:\MinGW-Projects\gg>lib /machine:i386 /def:TADll.def
Microsoft (R) Library Manager Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

   Creating library TADll.lib and object TADll.exp

C:\MinGW-Projects\gg>dumpbin /exports TADll.lib
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file TADll.lib

File Type: LIBRARY

     Exports

       ordinal    name

             1    _bar@0
             2    _foo@0

  Summary

          BD .debug$S
          14 .idata$2
          14 .idata$3
           4 .idata$4
           4 .idata$5
           A .idata$6

While linking the DLL, I've asked LD to generate a .DEF file for me with "-Wl,--output-def,TADll.def". I then use MSVC's LIB tool to generate an import lib using the .def.

gg

[John E]

The thing is, MinGW does not produce .lib files. Typically only MS tools create those.

So "how" they are creating the .lib seems to be the problem.

[...]

While linking the DLL, I've asked LD to generate a .DEF file for me with "-Wl,--output-def,TADll.def". I then use MSVC's LIB tool to generate an import lib using the .def.

Ah, this is starting to make sense now. Thanks for all your effort Codeplug.

Since I don't have MinGW available could I ask you a small favour? Would you look inside the DEF file that got created and see if it contains ordinal numbers alongside the function names? If it does, that explains the problem. He needs to be able to generate a DEF file with no ordinal numbers.

[Paul McKenzie]

Ah, this is starting to make sense now.

The import library that is produced by Visual C++ was produced by the program LINK.EXE, and is proprietary to the Visual C++ product.

If you have the Borland compiler, they have a different import library format, and I bet that ld (which is what MingW really calls underneath to link) uses another format for their version of import libraries.

So you cannot mix and match import libraries produced by different compiler/linker products.

Regards,

Paul McKenzie

[Codeplug]

>> If it does, that explains the problem.
I just now realized that ordinals in a .DEF will cause the imports to be resolved by ordinal instead of by name

>> Would you look inside the DEF file that got created ...
That was in my output. The DEF and resulting LIB have ordinals. When MSVC links with that LIB, the resulting EXE under Dependency Walker shows the imports being resolved by ordinal.

I don't see an option to tell LD not to generate the ordinals. Probably easiest to just have a script remove the ordinals before calling lib.exe.

gg