WINEDLLPATH and /usr/lib/wine
Hi, I am wanting to direct wine to launch a specific APP.exe.so program by using WINEDLLPATH during the development of APP.exe. Unfortunately (and undocumented-ely if you know what I mean) WINEDLLPATH is superseded by /usr/lib/wine. So if /usr/lib/wine/APP.exe.so exists, WINEDLLPATH will find that one instead of the one I am trying to target. So, if these files exist: /usr/lib/wine/APP.exe.so /MY_DIR/APP.exe.so Then this command... WINEDLLPATH=MY_DIR wine APP.exe ... will start /usr/lib/wine/APP.exe.so and not /MY_DIR/APP.exe.so. Is this on purpose? It doesn't seem right at first glance. I would assume that WINEDLLPATH would take precedence. Otherwise what purpose would it serve? Thanks for tips or background, Michael Ost Muse Research, Inc.
I asked about the same problem a while ago without any response, but I have a patch for it: https://www.linuxfoundation.org/en/User:Htl10#Ddiwrapper_.28a.k.a._.22Using_... I reckon it is because the wine devs don't want people to override certain things. WINEDLLPATH used to work until Feb/March 2006 . --- On Mon, 25/1/10, Michael Ost <most(a)museresearch.com> wrote:
Hi,
I am wanting to direct wine to launch a specific APP.exe.so program by using WINEDLLPATH during the development of APP.exe.
Unfortunately (and undocumented-ely if you know what I mean) WINEDLLPATH is superseded by /usr/lib/wine. So if /usr/lib/wine/APP.exe.so exists, WINEDLLPATH will find that one instead of the one I am trying to target.
So, if these files exist: /usr/lib/wine/APP.exe.so /MY_DIR/APP.exe.so
Then this command... WINEDLLPATH=MY_DIR wine APP.exe ... will start /usr/lib/wine/APP.exe.so and not /MY_DIR/APP.exe.so.
Is this on purpose? It doesn't seem right at first glance. I would assume that WINEDLLPATH would take precedence. Otherwise what purpose would it serve?
Thanks for tips or background, Michael Ost Muse Research, Inc.
Hin-Tak Leung wrote:
I asked about the same problem a while ago without any response, but I have a patch for it:
https://www.linuxfoundation.org/en/User:Htl10#Ddiwrapper_.28a.k.a._.22Using_...
I can see how that patch would work. Though I can also see why it wouldn't be accepted! :) I'll let you know if I come up with something else that doesn't need a patch - though I am not hopeful. Thanks ... mo
I reckon it is because the wine devs don't want people to override certain things. WINEDLLPATH used to work until Feb/March 2006 . --- On Mon, 25/1/10, Michael Ost <most(a)museresearch.com> wrote:
Hi,
I am wanting to direct wine to launch a specific APP.exe.so program by using WINEDLLPATH during the development of APP.exe.
Unfortunately (and undocumented-ely if you know what I mean) WINEDLLPATH is superseded by /usr/lib/wine. So if /usr/lib/wine/APP.exe.so exists, WINEDLLPATH will find that one instead of the one I am trying to target.
So, if these files exist: /usr/lib/wine/APP.exe.so /MY_DIR/APP.exe.so
Then this command... WINEDLLPATH=MY_DIR wine APP.exe ... will start /usr/lib/wine/APP.exe.so and not /MY_DIR/APP.exe.so.
Is this on purpose? It doesn't seem right at first glance. I would assume that WINEDLLPATH would take precedence. Otherwise what purpose would it serve?
Thanks for tips or background, Michael Ost Muse Research, Inc.
--- On Mon, 25/1/10, Michael Ost <most(a)museresearch.com> wrote:
Hin-Tak Leung wrote:
I asked about the same problem a while ago without any response, but I have a patch for it:
https://www.linuxfoundation.org/en/User:Htl10#Ddiwrapper_.28a.k.a._.22Using_...
I can see how that patch would work. Though I can also see why it wouldn't be accepted! :) I'll let you know if I come up with something else that doesn't need a patch - though I am not hopeful.
Well, the patch wasn't intended to be submitted as is - all it does is partially reverting this particularly commit, which I asked about witout hearing an answer. Posting the patch is more as a way of showing where the location of discussion is. -------------------------- commit 1269f43c5a68e03b526098fb18dd0edd42858ceb Author: Alexandre Julliard <julliard(a)winehq.org> Date: Fri Feb 17 17:39:44 2006 +0100 libwine: Add the runtime library path to the front of the dll paths list. ---------------------------- Obviously, if you come up with something better and more acceptable for inclusion to wine I'd love to see it.
Michael Ost <most(a)museresearch.com> writes:
Is this on purpose? It doesn't seem right at first glance. I would assume that WINEDLLPATH would take precedence. Otherwise what purpose would it serve?
It serves as an extra path where dlls can be found, but dlls from the current running installation are used first. This is to enable relocatable installs, and running from inside the build tree. Note that you can always specify the full exe path on the command line. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
Michael Ost <most(a)museresearch.com> writes:
Is this on purpose? It doesn't seem right at first glance. I would assume that WINEDLLPATH would take precedence. Otherwise what purpose would it serve?
It serves as an extra path where dlls can be found, but dlls from the current running installation are used first. This is to enable relocatable installs, and running from inside the build tree. Note that you can always specify the full exe path on the command line.
That doesn't work without a wine drive that includes APP.exe.so --- we run without z:/. I think it makes more sense to require, as Hin-Tak Leung's patch does, that a user put /usr/lib/wine in WINEDLLPATH if they use WINEDLLPATH. This is how LD_LIBRARY_PATH works for ld and PATH works in bash --- so it's expected behavior. Also, from my reading of the code, you jump through some special hoops to deal with running from the build directory which could be more easily solved by putting WINEDLLPATH first. Anyway, I'm guessing that I'm whistling in the wind here since so much is built on how WINEDLLPATH currently works...? Thanks... mo
Michael Ost <most(a)museresearch.com> writes:
I think it makes more sense to require, as Hin-Tak Leung's patch does, that a user put /usr/lib/wine in WINEDLLPATH if they use WINEDLLPATH. This is how LD_LIBRARY_PATH works for ld and PATH works in bash --- so it's expected behavior.
Also, from my reading of the code, you jump through some special hoops to deal with running from the build directory which could be more easily solved by putting WINEDLLPATH first.
Anyway, I'm guessing that I'm whistling in the wind here since so much is built on how WINEDLLPATH currently works...?
Not necessarily, the behavior could probably be tweaked, feel free to suggest changes. You can't require users to set WINEDLLPATH for normal usage though, including running from the build tree or from a relocated install. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
Michael Ost <most(a)museresearch.com> writes:
I think it makes more sense to require, as Hin-Tak Leung's patch does, that a user put /usr/lib/wine in WINEDLLPATH if they use WINEDLLPATH. This is how LD_LIBRARY_PATH works for ld and PATH works in bash --- so it's expected behavior.
Also, from my reading of the code, you jump through some special hoops to deal with running from the build directory which could be more easily solved by putting WINEDLLPATH first.
Anyway, I'm guessing that I'm whistling in the wind here since so much is built on how WINEDLLPATH currently works...?
Not necessarily, the behavior could probably be tweaked, feel free to suggest changes. You can't require users to set WINEDLLPATH for normal usage though, including running from the build tree or from a relocated install.
Two easy options would be: 1. put /usr/lib/wine at the end of the list automatically. This is Hin-Tak Leung's approach. 2. require users to add /usr/lib/wine themselves. I could make a patch for that. #1 is easier for me :) but #2 is a little more "standard", acting like LD_LIBRARY_PATH or PATH do. Which would you prefer? ... mo
--- On Mon, 25/1/10, Michael Ost <most(a)museresearch.com> wrote:
Alexandre Julliard wrote:
Not necessarily, the behavior could probably be tweaked, feel free to suggest changes. You can't require users to set WINEDLLPATH for normal usage though, including running from the build tree or from a relocated install.
Two easy options would be: 1. put /usr/lib/wine at the end of the list automatically. This is Hin-Tak Leung's approach. 2. require users to add /usr/lib/wine themselves. I could make a patch for that.
#1 is easier for me :) but #2 is a little more "standard", acting like LD_LIBRARY_PATH or PATH do.
Which would you prefer? ... mo
If I understand that bit of code correctly, the current behavior is such that built-ins comes before WINEDLLPATH *and* after, so there is no way a user per-application built-ins can override (even temporarily on a per application basis) the system-wide built-ins. As ddiwrapper - the application I was interested in - tried to provide a gdl32.dll.so which does different things - it stopped working when the system-wide built-ins is both prepended and appended to library search. I think it should work like LD_LIBRARY_PATH, really as they are platform shared libraries. There is, of course a rather absurd way of working around the current situation - cross-compilating the override desired as win32 PE's (then WINEDLLOVERRIDES does work) - but this doesn't quite work, for things like ddiwrapper again, as it actually wants to do host-native (linux-) things, rather than win32-only things.
2010/1/26 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>:
--- On Mon, 25/1/10, Michael Ost <most(a)museresearch.com> wrote:
Alexandre Julliard wrote:
Not necessarily, the behavior could probably be tweaked, feel free to suggest changes. You can't require users to set WINEDLLPATH for normal usage though, including running from the build tree or from a relocated install.
Two easy options would be: 1. put /usr/lib/wine at the end of the list automatically. This is Hin-Tak Leung's approach. 2. require users to add /usr/lib/wine themselves. I could make a patch for that.
#1 is easier for me :) but #2 is a little more "standard", acting like LD_LIBRARY_PATH or PATH do.
Which would you prefer? ... mo
If I understand that bit of code correctly, the current behavior is such that built-ins comes before WINEDLLPATH *and* after, so there is no way a user per-application built-ins can override (even temporarily on a per application basis) the system-wide built-ins.
As ddiwrapper - the application I was interested in - tried to provide a gdl32.dll.so which does different things - it stopped working when the system-wide built-ins is both prepended and appended to library search.
For DLLs at least, you should be able to rename the .dll.so to a .dll and stick it in the application's directory. I don't recall the last time I tried this, but it certainly worked (I was using a hacked ddraw.dll.so to get Diablo and Worms Armageddon playing nicely). I assume you could do something similar for EXEs.
I think it should work like LD_LIBRARY_PATH, really as they are platform shared libraries.
There is, of course a rather absurd way of working around the current situation - cross-compilating the override desired as win32 PE's (then WINEDLLOVERRIDES does work) - but this doesn't quite work, for things like ddiwrapper again, as it actually wants to do host-native (linux-) things, rather than win32-only things.
Is there some specific reason why you *need* WINEDLLPATH to override standard built-ins? Is your APP.exe.so being called by some other process that does not specify the full path, or something along those lines?
--- On Tue, 26/1/10, Ben Klein <shacklein(a)gmail.com> wrote:
For DLLs at least, you should be able to rename the .dll.so to a .dll and stick it in the application's directory. I don't recall the last time I tried this, but it certainly worked (I was using a hacked ddraw.dll.so to get Diablo and Worms Armageddon playing nicely). I assume you could do something similar for EXEs.
Thanks for the tips - that sounds a bit wrong though, so's are not PE dll's :-). It is a nice hack and probably should/could be documented somewhere.
Is there some specific reason why you *need* WINEDLLPATH to override standard built-ins? Is your APP.exe.so being called by some other process that does not specify the full path, or something along those lines?
ddiwrapper (doing printing using vendor dll) uses a hacked-up gdi32 to receive bitmaps from the host's ghostscript to feed to the vendor printing dll. I didn't write the code - this is my understanding of how it works.
Hin-Tak Leung wrote:
--- On Mon, 25/1/10, Michael Ost <most(a)museresearch.com> wrote:
Alexandre Julliard wrote:
Not necessarily, the behavior could probably be tweaked, feel free to suggest changes. You can't require users to set WINEDLLPATH for normal usage though, including running from the build tree or from a relocated install. Two easy options would be: 1. put /usr/lib/wine at the end of the list automatically. This is Hin-Tak Leung's approach. 2. require users to add /usr/lib/wine themselves. I could make a patch for that.
#1 is easier for me :) but #2 is a little more "standard", acting like LD_LIBRARY_PATH or PATH do.
Which would you prefer? ... mo
If I understand that bit of code correctly, the current behavior is such that built-ins comes before WINEDLLPATH *and* after, so there is no way a user per-application built-ins can override (even temporarily on a per application basis) the system-wide built-ins.
Yes, I can confirm this. Strange to have it in the list twice. That sure looked unintentional to me.
As ddiwrapper - the application I was interested in - tried to provide a gdl32.dll.so which does different things - it stopped working when the system-wide built-ins is both prepended and appended to library search. I think it should work like LD_LIBRARY_PATH, really as they are platform shared libraries.
I agree. And that's what your patch does, right? Would you like to submit it to the wine-patches list? I think the case for it is strong, especially since (1) you found that it fixes a behavior change in WINEDLLPATH from November 2006 --- arguably a regression; and (2) it works in the same way that LD_LIBRARY_PATH works, which is what Linux programmers would expect. If you want to help future WINEDLLPATH users, you could also tweak the man page from something like: "WINEDLLPATH Specifies the path(s) in which to search for builtin dlls and Winelib applications. This is a list of directories separated by ":". In addition to any directory specified in WINEDLLPATH, Wine will also look in /usr/lib/wine." to something like: "WINEDLLPATH Specifies the path(s) in which to search for builtin dlls and Winelib applications. This is a list of directories separated by ":". After looking in directories specified in WINEDLLPATH, Wine will also look in /usr/lib/wine." Cheers... mo
Michael Ost <most(a)museresearch.com> writes:
I agree. And that's what your patch does, right? Would you like to submit it to the wine-patches list? I think the case for it is strong, especially since (1) you found that it fixes a behavior change in WINEDLLPATH from November 2006 --- arguably a regression; and (2) it works in the same way that LD_LIBRARY_PATH works, which is what Linux programmers would expect.
Actually the current way is precisely what LD_LIBRARY_PATH does for relocatable installs. The loader first looks in the rpath $ORIGIN path, then in LD_LIBRARY_PATH, then in system directories. Wine does exactly the same thing. -- Alexandre Julliard julliard(a)winehq.org
--- On Tue, 26/1/10, Alexandre Julliard <julliard(a)winehq.org> wrote:
Michael Ost <most(a)museresearch.com> writes:
I agree. And that's what your patch does, right? Would you like to submit it to the wine-patches list? I think the case for it is strong, especially since (1) you found that it fixes a behavior change in WINEDLLPATH from November 2006 --- arguably a regression; and (2) it works in the same way that LD_LIBRARY_PATH works, which is what Linux programmers would expect.
Actually the current way is precisely what LD_LIBRARY_PATH does for relocatable installs. The loader first looks in the rpath $ORIGIN path, then in LD_LIBRARY_PATH, then in system directories. Wine does exactly the same thing.
I suppose that's the intention of specifying rpath (and that change back in feb 2006?) - some are security-conscious and wish built-in bits not to be overridable. I agree most uses of LD_LIBRARY_PATH are fairly ugly hacks, and if it is needed somebody is probably doing something wrong. (on the issue with ddiwrapper - supposedly its use of WINEDLLPATH shouldn't be needed if wine's gdi32 and friends have a more complete implementations of DIB, the *Eng* routines, I think... so it is band-aiding over an issue, but it is a band-aid useful to some people, alright).
Alexandre Julliard wrote:
Michael Ost <most(a)museresearch.com> writes:
I agree. And that's what your patch does, right? Would you like to submit it to the wine-patches list? I think the case for it is strong, especially since (1) you found that it fixes a behavior change in WINEDLLPATH from November 2006 --- arguably a regression; and (2) it works in the same way that LD_LIBRARY_PATH works, which is what Linux programmers would expect.
Actually the current way is precisely what LD_LIBRARY_PATH does for relocatable installs. The loader first looks in the rpath $ORIGIN path, then in LD_LIBRARY_PATH, then in system directories. Wine does exactly the same thing.
I did a quickie review of 'rpath'. It isn't standard, though, is it? I'm not using it with my APP.exe.so. LD_LIBRARY_PATH is searched first on my system. Anyway, is the next step that I (or Hin-Tak) submit a patch and you bless it or not? - mo PS: LD_LIBRARY_PATH behavior with my .exe.so shows that LD_LIBRARY_PATH can jump in front of even /lib... [most(a)Deceptor make]$ ldd wine-debug/host-engine.exe.so libdl.so.2 => /lib/libdl.so.2 (0xb7b9b000) <snip> [most(a)Deceptor make]$ ls /lib/libdl.so.2 /lib/libdl.so.2 [most(a)Deceptor make]$ touch libdl.so.2 [most(a)Deceptor make]$ LD_LIBRARY_PATH=`pwd` ldd wine-debug/host-engine.exe.so /bin/bash: error while loading shared libraries: /home/most/Desktop/cvs/muse/applications/host-engine/make/libdl.so.2: file too short
Michael Ost <most(a)museresearch.com> writes:
Alexandre Julliard wrote:
Actually the current way is precisely what LD_LIBRARY_PATH does for relocatable installs. The loader first looks in the rpath $ORIGIN path, then in LD_LIBRARY_PATH, then in system directories. Wine does exactly the same thing.
I did a quickie review of 'rpath'. It isn't standard, though, is it? I'm not using it with my APP.exe.so. LD_LIBRARY_PATH is searched first on my system.
Yes, it's pretty standard (or has equivalent on other platforms). Wine itself uses it.
Anyway, is the next step that I (or Hin-Tak) submit a patch and you bless it or not?
The first step would probably be to explain why you need to have an app with the same name as an existing builtin. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
Michael Ost <most(a)museresearch.com> writes: The first step would probably be to explain why you need to have an app with the same name as an existing builtin.
Right, ok. I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so all users from any .wine directory can launch it with a script that contains 'exec wine APP.exe'. I'm mimicking how, say, regedit works. During development I want to run a development-local APP.exe.so in place of the version installed in /usr/lib/wine. 'WINEDLLPATH=/DEVDIR wine APP.exe' was my solution. The solution of using a hardcoded path doesn't work for me because (a) my development directory is not accessible through a wine drive so wine can't find APP.exe.so and (b) we have code that uses 'pidof APP.exe' to find APP's pid, so if it were named APP.exe.so it would not be found. Granted there are other solutions to these issues. But using WINEDLLPATH is an elegant one. Unfortunately WINEDLLPATH does not work as I expected it to, based on experience with other similar Linux features (like ld) and reading the wine man page. Thanks... mo PS: Did you know that currently the search path is (mysteriously) /usr/lib/wine:WINEDLLPATH:/usr/lib/wine? That doesn't look intentional to me...
Michael Ost <most(a)museresearch.com> writes:
I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so all users from any .wine directory can launch it with a script that contains 'exec wine APP.exe'. I'm mimicking how, say, regedit works.
During development I want to run a development-local APP.exe.so in place of the version installed in /usr/lib/wine. 'WINEDLLPATH=/DEVDIR wine APP.exe' was my solution.
If it's just for development I don't think this justifies changing it. You could simply use your own Wine build and then it will ignore the one in /usr/lib/wine, or configure a drive for your development dir.
PS: Did you know that currently the search path is (mysteriously) /usr/lib/wine:WINEDLLPATH:/usr/lib/wine? That doesn't look intentional to me...
The first one is not /usr/lib/wine, it's wherever the Wine install has been relocated too. That's how rpath works, and it's very much intentional. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
Michael Ost <most(a)museresearch.com> writes:
I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so all users from any .wine directory can launch it with a script that contains 'exec wine APP.exe'. I'm mimicking how, say, regedit works.
During development I want to run a development-local APP.exe.so in place of the version installed in /usr/lib/wine. 'WINEDLLPATH=/DEVDIR wine APP.exe' was my solution.
If it's just for development I don't think this justifies changing it. You could simply use your own Wine build and then it will ignore the one in /usr/lib/wine, or configure a drive for your development dir.
Alright, I'll just add the patch to our own internal wine build then. Well I tried! ... mo
--- On Wed, 27/1/10, Alexandre Julliard <julliard(a)winehq.org> wrote:
The first step would probably be to explain why you need to have an app with the same name as an existing builtin.
ddiwrapper provides its own gdi32.dll.so winspool.drv.so , so that bitmap generated by the host's ghostscript is fed into the printer vendor's driver dlll via gdi32 and the result retrieved back to fed to the printer port. This allows some printers for which native driver is not available to work...
2010/1/26 Michael Ost <most(a)museresearch.com>:
Alexandre Julliard wrote:
Note that you can always specify the full exe path on the command line.
That doesn't work without a wine drive that includes APP.exe.so --- we run without z:/.
This sort of configuration is impossible to support. You should have a wine drive that includes your APP.exe.so, but that doesn't need to be the default Z: mapping. What happens if the app wants DLLs from its own directory?
I think it makes more sense to require, as Hin-Tak Leung's patch does, that a user put /usr/lib/wine in WINEDLLPATH if they use WINEDLLPATH. This is how LD_LIBRARY_PATH works for ld and PATH works in bash --- so it's expected behavior.
Actually, it's not how LD_LIBRARY_PATH works. $ LD_LIBRARY_PATH=/path/that/does/not/exist/ /bin/echo Hi there Hi there It is the way it works for PATH in all shells (not just bash), but this is a different matter because your shell environment (often a login or profile script) provides a default, sensible value for PATH. $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/games $ echo $LD_LIBRARY_PATH WINEDLLPATH should certainly behave more like LD_LIBRARY_PATH than PATH, but wine should always follow the same DLL search pattern as Windows. How would Windows handle adding a directory to the DLL search path? (Is this even possible?)
Also, from my reading of the code, you jump through some special hoops to deal with running from the build directory which could be more easily solved by putting WINEDLLPATH first.
How, exactly?
Anyway, I'm guessing that I'm whistling in the wind here since so much is built on how WINEDLLPATH currently works...?
Thanks... mo
Ben Klein wrote:
2010/1/26 Michael Ost <most(a)museresearch.com>:
Alexandre Julliard wrote: I think it makes more sense to require, as Hin-Tak Leung's patch does, that a user put /usr/lib/wine in WINEDLLPATH if they use WINEDLLPATH. This is how LD_LIBRARY_PATH works for ld and PATH works in bash --- so it's expected behavior.
Actually, it's not how LD_LIBRARY_PATH works. $ LD_LIBRARY_PATH=/path/that/does/not/exist/ /bin/echo Hi there Hi there
It is the way it works for PATH in all shells (not just bash), but this is a different matter because your shell environment (often a login or profile script) provides a default, sensible value for PATH. $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/games $ echo $LD_LIBRARY_PATH
OK - fair enough. But, if I read the man page correctly LD_LIBRARY_PATH _prepends_ your path before the standard paths. That would do fine for me. WINEDLLPATH is appended after /usr/lib/wine.
WINEDLLPATH should certainly behave more like LD_LIBRARY_PATH than PATH, but wine should always follow the same DLL search pattern as Windows. How would Windows handle adding a directory to the DLL search path? (Is this even possible?)
I'm not getting why Windows DLL searching is relevant here. This is a Linux-side issue.
Also, from my reading of the code, you jump through some special hoops to deal with running from the build directory which could be more easily solved by putting WINEDLLPATH first.
How, exactly?
This was a slightly uninformed comment on my part, so I could be totally off base here. And the code supporting dll directory lookups is complicated. But ... I saw special cases for dealing with the build directory, including this comment "/* if no build dir skip all the build dir magic cases */" libs/wine/loader.c/first_dll_path. Those suggest to me that someone was trying to stick a path in before /usr/lib/wine. All that said, this isn't at all central to what I would like to do. All I want is that WINEDLLPATH comes before /usr/lib/wine. - mo PS: Hin-Tak Leung, who got bit by this before me, found that WINEDLLPATH broke/changed in November of 2006.
2010/1/26 Michael Ost <most(a)museresearch.com>:
Ben Klein wrote:
WINEDLLPATH should certainly behave more like LD_LIBRARY_PATH than PATH, but wine should always follow the same DLL search pattern as Windows. How would Windows handle adding a directory to the DLL search path? (Is this even possible?)
I'm not getting why Windows DLL searching is relevant here. This is a Linux-side issue.
Because Wine has to emulate Windows behaviour, whether it's unix-like behaviour or not.
Also, from my reading of the code, you jump through some special hoops to deal with running from the build directory which could be more easily solved by putting WINEDLLPATH first.
How, exactly?
This was a slightly uninformed comment on my part, so I could be totally off base here. And the code supporting dll directory lookups is complicated. But ... I saw special cases for dealing with the build directory, including this comment "/* if no build dir skip all the build dir magic cases */" libs/wine/loader.c/first_dll_path. Those suggest to me that someone was trying to stick a path in before /usr/lib/wine.
Yes, this is specifically so that you can test wine from a build directory without having to install it. Without this, regression testing would be virtually impossible. I don't see how sticking WINEDLLPATH at the top of the list will help.
All that said, this isn't at all central to what I would like to do. All I want is that WINEDLLPATH comes before /usr/lib/wine.
- mo
PS: Hin-Tak Leung, who got bit by this before me, found that WINEDLLPATH broke/changed in November of 2006.
There are other ways to acheive what you're trying to do, like setting up a wine drive that points to wherever you're developing your custom APP.exe.so and specifying the complete path on the commandline.
participants (4)
-
Alexandre Julliard -
Ben Klein -
Hin-Tak Leung -
Michael Ost