idata allegedly missing (Win32)

[Jan Beulich]

On 02.05.2025 16:08, Paul Edwards wrote:
> 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.
> 
> 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.

I can only say as much here: I never understood why this synthesizing
isn't done by MSVC's link.exe. But they're the standard in that world,
and hence I think we can kind of expect that we also don't need to do
such synthesization (unless someone wanted to come forward and
contribute respective code).

> 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

So aiui to achieve this they must be doing _some_ synthesization.

> 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?

I don't know the code well enough to say "yes" or "no" here. It has to remain
at the earlier "may". What I do know is that there are some, well, horrifying
heuristics involved. Which is where the "may" is coming from.

> Even a
> cryptic error message would be better than silently
> producing a rogue executable.

I certainly agree here.

Jan