> Date: Tue, 29 Jul 2025 18:53:41 +0200 > From: Patrice Dumas <pertu...@free.fr> > Cc: bug-texinfo@gnu.org > > On Tue, Jul 29, 2025 at 07:04:27PM +0300, Eli Zaretskii wrote: > > It's very simple: you need to make sure the directory where the DLL > > lives is on PATH or in the same directory from where you invoke the > > program which needs the DLL. > > Are you sure that what you describe is valid for Perl extensions?
That's how Windows finds DLLs, regardless of their purpose. > We > often load objects (through Perl Dynaloader) that are in different > locations that seems to be loaded (through something like dlopen) as > long as the filename is available. If the file name includes leading directories, and is correct, it doesn't have to be on PATH. But I'm not sure the file name is correct in these cases > Looking a Dynaloader code, it seems that the function actually used on > win32 (which I assume to be used for cygwin) is Win_GetModuleHandle, > which could actually be GetModuleHandle (since I can't find anything on > internet about Win_GetModuleHandle). GetModuleHandle is only relevant when the module (DLL in this case) was already loaded into the process. Not sure how it is relevant here. What happens if you copy the DLL to the place where DynaLoader.pm claims that it looks for it. IOW, replace the symlink with a copy of the DLL itself. Does the problem go away?
