Open spth opened 7 months ago
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.
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.
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 .dll
s 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.
Yes, the title is the same as https://github.com/suve/copydeps/issues/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):