idata allegedly missing (Win32)

[Paul Edwards]

On Fri, May 2, 2025 at 4:11 PM Jan Beulich <jbeulich@suse.com> wrote:

> >> And he notes that gnu ld apparently silently fails instead of
> >> giving an error. So I assume you don't think that is appropriate
> >> behavior. If you don't want libraries produced by other tools
> >> to be used - fine, but at least produce an error message when
> >> someone provides a "bad" library. ie don't silently produce a
> >> bad executable that fails without explanation.
>
> Well, yes, that would be best. Given some of the internals of the linker
> work here, that simply may not be feasible here without risking to emit
> false warnings.

Hi Jan.

Thanks for your reply.

The pdld author has responded with:


The archive members present in pdld msvcrt.lib contain the DLL name in
Import Header (https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#import-header)
as the second null-terminated string.

The DLL name in Import Header is sufficient to generate the data
contained in the 3 missing archive members or to provide a warning by
generating undefined symbol __IMPORT_DESCRIPTOR_<dllname> which will
become defined in supported archives (but not in pdld msvcrt.lib) as
they contain the needed archive member, so no false warning would
occur.


Note that Microsoft's link gives errors like this when I try to use
it with a library created by pdld (in this case, kernel32.lib, not
msvcrt.lib:

D:\devel\pdos\pdpclib>pdmake -f makefile.msw
...
ml -nologo -c -coff winsupa.asm
 Assembling: winsupa.asm
rm -f pdpwin32.lib
lib -nologo -out:temp1.lib p32start.obj stdio.obj string.obj stdlib.obj winsupa.
obj
lib -nologo -out:temp2.lib start.obj time.obj errno.obj assert.obj signal.obj
lib -nologo -out:temp3.lib locale.obj ctype.obj setjmp.obj math.obj __memmgr.obj

lib -nologo -out:pdpwin32.lib temp1.lib temp2.lib temp3.lib
del temp*.lib
link -map -nologo -fixed:no -nodefaultlib -out:pdptest.exe p32start.obj pdptest.
obj pdpwin32.lib ../src/kernel32.lib
kernel32.lib(IMPORT) : error LNK2001: unresolved external symbol __IMPORT_DESCRI
PTOR_kernel32
kernel32.lib(IMPORT) : error LNK2001: unresolved external symbol __IMPORT_DESCRI
PTOR_kernel32
kernel32.lib(IMPORT) : error LNK2001: unresolved external symbol __IMPORT_DESCRI
PTOR_kernel32


I know where I stand with Visual Studio and no rogue
executable is created.

So as you noted already - that would be ideal, but there
may be technical issues. Do you still believe there are
technical issues preventing some sort of error? Even a
cryptic error message would be better than silently
producing a rogue executable.

Thanks. Paul.