Hmm, OK. I don't know which this person was using. Why is /usr/lib/wine even added to ld.so.conf though, surely that isn't necessary? Only libwine needs to be in the linker path.
libs are in /usr/lib/wine and dlls are in /usr/lib/wine/dlls, not adding /usr/lib/wine to ld.so.conf causes wine to fail, as it doesn't find ntdll.dll.so. There are alternative solutions, but this looks good to me, keeps dirs tidy and has always worked.
Ivan.
On Thu, Jan 08, 2004 at 10:10:59PM +0100, Ivan Leo Murray-Smith wrote:
Hmm, OK. I don't know which this person was using. Why is /usr/lib/wine even added to ld.so.conf though, surely that isn't necessary? Only libwine needs to be in the linker path.
libs are in /usr/lib/wine and dlls are in /usr/lib/wine/dlls, not adding /usr/lib/wine to ld.so.conf causes wine to fail, as it doesn't find ntdll.dll.so. There are alternative solutions, but this looks good to me, keeps dirs tidy and has always worked.
No!
rpm -ql wine ... /usr/lib/libwine.so /usr/lib/libwine.so.1 /usr/lib/libwine_unicode.so /usr/lib/libwine_unicode.so.1 /usr/lib/libwine_uuid.a
These are all libraries that belong to /usr/lib. All others (<dllname>.dll.so dlls must go to /usr/lib/wine/).
libwine.so will look and find them in /usr/lib/wine/ by default when trying to load them.
There is NO need to add /usr/lib/wine to ld.so.conf!
Ciao, Marcus
On Thu, 2004-01-08 at 21:10, Ivan Leo Murray-Smith wrote:
libs are in /usr/lib/wine and dlls are in /usr/lib/wine/dlls, not adding /usr/lib/wine to ld.so.conf causes wine to fail, as it doesn't find ntdll.dll.so.
Works here. I only have /opt/wine/lib in my ld.so.conf, which doesn't contain any of the dlls.
There are alternative solutions, but this looks good to me, keeps dirs tidy and has always worked.
The problem with this is that it's different to the layout used by the source installs, so giving tech support on #winehq etc becomes that much harder. It seems to be different simply for the sake of being different.
Mike Hearn mike@theoretic.com writes:
The problem with this is that it's different to the layout used by the source installs, so giving tech support on #winehq etc becomes that much harder. It seems to be different simply for the sake of being different.
Actually there used to be a reason to do that, when dlls needed to be in the Unix library path to get loaded properly. The default was to add symlinks in /usr/lib, but it wasn't very clean to have a bunch of dlls in there so it made sense for packages to put everything in /usr/lib/wine instead and change ld.so.conf. However this is fixed now, and today there's no reason to change the standard layout.
On Thu, 2004-01-08 at 22:06, Alexandre Julliard wrote:
Actually there used to be a reason to do that, when dlls needed to be in the Unix library path to get loaded properly. The default was to add symlinks in /usr/lib, but it wasn't very clean to have a bunch of dlls in there so it made sense for packages to put everything in /usr/lib/wine instead and change ld.so.conf. However this is fixed now, and today there's no reason to change the standard layout.
While we're on the topic, it seems that Wine figures out where the dlls are either by using a compiled in macro or by read an environment variable. As part of my other project, we developed a small piece of C that reads /proc to determine the prefix of any given ELF object so it becomes possible to make binary relocatable Linux programs easily.
Would you accept a patch to use this code on Linux systems to figure out where to load the DLLs from? That way Wine can be installed to any prefix and it works automatically, no need for wrapper scripts or anything like that.
thanks -mike
Mike Hearn mike@theoretic.com writes:
Would you accept a patch to use this code on Linux systems to figure out where to load the DLLs from? That way Wine can be installed to any prefix and it works automatically, no need for wrapper scripts or anything like that.
Well, it could maybe be added as an option, but I don't think it would work in all cases, since it will necessarily add different constraints on the layout (for instance you need to hardcode that the dlls are in ../lib/wine relative to the binary, which may or may not be what you want).
On Thu, 2004-01-08 at 22:44, Alexandre Julliard wrote:
Well, it could maybe be added as an option, but I don't think it would work in all cases, since it will necessarily add different constraints on the layout (for instance you need to hardcode that the dlls are in ../lib/wine relative to the binary, which may or may not be what you want).
Sure, that's understood. The idea of this is purely that for programs that follow the FHS and have a standard layout we can easily make the binary relocatable. It wouldn't replace the existing search mechanisms.
thanks -mike
-
Alexandre Julliard -
Ivan Leo Murray-Smith -
Marcus Meissner -
Mike Hearn