Copydeps cannot resolve any dll

[spth]

Yes, the title is the same as #11, but there the reply was "The simple truth is I've written this to be a Linux tool and never gave running under Windows any thought."

I'm seeing what looks like the same problem on Debian GNU/Linux. E.g. (small example, so there is only one DLL that should be found, but I see the same "failed to resolve" with other programs that need more DLLs):

sdcc-builder@notebook6:~$ /tmp/copydeps/build/copydeps --dry-run ./build/sdcc-build/build/x86_64-w64-mingw32/sdcc/sdcc/bin/sdar.exe
"KERNEL32.dll": (ignored)
"USER32.dll": (ignored)
"msvcrt.dll": (ignored)
"zlib1.dll": (failed to resolve)
sdcc-builder@notebook6:~$ find /usr -name zlib1.dll
/usr/lib/x86_64-linux-gnu/wine/zlib1.dll
/usr/lib/x86_64-linux-gnu/wine/i386-windows/zlib1.dll
/usr/lib/x86_64-linux-gnu/wine/x86_64-windows/zlib1.dll
/usr/lib/i386-linux-gnu/wine/zlib1.dll
/usr/lib/i386-linux-gnu/wine/i386-windows/zlib1.dll
/usr/lib/i386-linux-gnu/wine/x86_64-windows/zlib1.dll
/usr/i686-w64-mingw32/lib/zlib1.dll
/usr/x86_64-w64-mingw32/lib/zlib1.dll

[suve]

This is caused by the fact that library lookup paths are currently hard-coded in the executable, and different distros store the files in different paths. The program would need to get the library path from the system somehow. Issue #8 suggests consulting /etc/ld.so.conf for this. If you know of any other potential solution, let me know.

[suve]

Hm, so looking at how ldd does it, it just calls /usr/lib64/ld-linux-x86-64.so.2 --list. Calling ldd and parsing the output was what this program did initially, so I'm kinda hesitant about reverting back to that behaviour, but it seems to be the simplest way to go about this.

It must be noted, though, that this could only be used for ELF executables; a different mechanism would be needed to figure out where MinGW libraries used for linking .exe files are located.

[suve]

Ugh. Seems I was quite distracted yesterday. I glanced over your comment, saw "Debian" and didn't really notice the fact that you're trying to copy .dlls for a MinGW-compiled program. Hence all my blabbering about /etc/ld.so.conf and ldd and so on.

So, MinGW. Like I said earlier, library lookup paths are currently hard-coded. When looking for dependencies for 64-bit .exe files, the list consists of a single entry:

vec!["/usr/x86_64-w64-mingw32/sys-root/mingw/bin/"]

Extending this and adding /usr/x86_64-w64-mingw32/lib/ is straight-forward and would solve the issue in your particular case. So that's what I'm gonna do for now; in the long run, it would be very much preferable to come up with some kind of mechanism that'd allow the program to detect where MinGW stuff is located.