[Bug binutils/33749] New: DLL: import libraries cannot be used for --delayload

[fabrizio.ge at tiscali dot it]

https://sourceware.org/bugzilla/show_bug.cgi?id=33749

            Bug ID: 33749
           Summary: DLL: import libraries cannot be used for --delayload
           Product: binutils
           Version: 2.45.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: fabrizio.ge at tiscali dot it
  Target Milestone: ---

Created attachment 16544
  --> https://sourceware.org/bugzilla/attachment.cgi?id=16544&action=edit
MyDLL.lib created by dlltool, MyDLLcc.lib created by gcc, MyDLLclang.lib
created by clanf

Import libraries generated by Microsoft's compiler/linker can be used for
normal loading and for delay loading.

Import libraries generated by dlltool, or by passing `-Wl,--out-implib=<import
library name>` to gcc at link time, can only be used for normal loading.

A simple reproduction case. A trivial DLL has source dll.c

```
#include <windows.h>

__declspec(dllexport) void fnMyDll() {
   MessageBox(NULL, "Hello", "Hello", MB_OK);
}
```

and a header file Mydll.h
```
void fnMyDll();
```

A DLL can be created with the command
```
cc -shared -Wl,--out-implib=MyDllcc.lib dll.c -o MyDll.dll
```

An executable that uses it has source exe.c (largely taken from Microsoft docs)

```
#include <windows.h>
#include <delayimp.h>
#include "MyDll.h"
#include <stdio.h>

int main()
{
    BOOL TestReturn;
    // MyDLL.DLL will load at this point
    fnMyDll();

    //MyDLL.dll will unload at this point
    TestReturn = __FUnloadDelayLoadedDLL2("MyDll.dll");

    if (TestReturn)
        printf_s("\nDLL was unloaded");
    else
        printf_s("\nDLL was not unloaded");
}
```

and can be built either with clang
```
clang -fuse-ld=lld -o exe.exe exe.c -ldelayimp MyDLLcc.lib
-Wl,--delayload=MyDLL.dll
```

or with Microsoft cl (C/C++ Optimizing Compiler version 19.44.35222 for x64,
from Visual Studio 2022)
```
cl exe.c delayimp.lib MyDLLcc.lib /link /DELAYLOAD:MyDLL.dll /DELAY:UNLOAD
```

and in both cases an executable is created, that works as expected, but where
MyDLL.dll is *not* delay-loaded. One can see with Dependency Walker, or just by
deleting MyDLL.dll and noticing that the executable refuses to start because
MyDLL.dll cannot be found (if it were delay-loaded, it would start and fail at
runtime).

The same occurs if a file dll.def is created as follows
```
LIBRARY MyDLL
EXPORTS
fnMyDll
```
then MyDLL.lib is created with

```
dlltool -l MyDLL.lib -d dll.def
```

then exe.exe is linked with either clang or cl (just replace MyDLLcc.lib with
MyDLL.lib).

However, if clang is used to build MyDLL.dll
```
clang -fuse-ld=lld -o exe.exe exe.c -ldelayimp MyDLLclang.lib
-Wl,--delayload=MyDLL.dll
```
, an import library MyDLLclang.lib is also created. Building exe.exe with both
clang and cl (replacing MyDLL.lib with MyDLLclang.lib in the commands above)
gives the desired result.

So, the desired result would be that dlltool and/or ld became able to generate
an import library that works in both cases.

-- 
You are receiving this mail because:
You are on the CC list for the bug.