Re: libwine: Use rpath-based install name and library references for libwine on Mac.
Ken Thomases <ken(a)codeweavers.com> writes:
--- configure.ac | 3 ++- libs/wine/Makefile.in | 6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-)
It doesn't seem to work when installed: wine: failed to initialize: dlopen(/usr/local/lib/wine/ntdll.dll.so, 258): image not found -- Alexandre Julliard julliard(a)winehq.org
On Jan 11, 2013, at 11:13 AM, Alexandre Julliard wrote:
Ken Thomases <ken(a)codeweavers.com> writes:
--- configure.ac | 3 ++- libs/wine/Makefile.in | 6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-)
It doesn't seem to work when installed:
wine: failed to initialize: dlopen(/usr/local/lib/wine/ntdll.dll.so, 258): image not found
It works for me on Mac OS X 10.6.8. On which version of the OS were you testing? I assume you did indeed build it with the prefix /usr/local and there is a /usr/local/lib/wine/ntdll.dll.so. Is that right? What output do you get from the following commands: otool -L /usr/local/bin/wine otool -L /usr/local/lib/wine/ntdll.dll.so otool -lV /usr/local/bin/wine | grep -A3 RPATH Finally, in the development that lead to this patch, I noticed that the quoted "failed to initialize" trace only reports the error from the last attempt to open ntdll.dll.so. Can you hack libwine to trace the error from each failed attempt? Something like: diff --git a/libs/wine/loader.c b/libs/wine/loader.c index 302e9c1..bb5d8e6 100644 --- a/libs/wine/loader.c +++ b/libs/wine/loader.c @@ -830,6 +830,7 @@ void wine_init( int argc, char *argv[], char *error, int error_size ) if (default_dlldir[0] && context.index < nb_dll_paths + 2) nb_dll_paths--; break; } +else fprintf(stderr, "%s: failed for %s: %s\n", __func__, path, error); } free_dll_path( &context ); -Ken
Ken Thomases <ken(a)codeweavers.com> writes:
On Jan 11, 2013, at 11:13 AM, Alexandre Julliard wrote:
It doesn't seem to work when installed:
wine: failed to initialize: dlopen(/usr/local/lib/wine/ntdll.dll.so, 258): image not found
It works for me on Mac OS X 10.6.8. On which version of the OS were you testing?
10.6.8.
I assume you did indeed build it with the prefix /usr/local and there is a /usr/local/lib/wine/ntdll.dll.so. Is that right?
The prefix is /usr/local, but there are no files in there, I moved them somewhere else. That's the whole point, files are supposed to be found relative to the binary, not in the hardcoded prefix. -- Alexandre Julliard julliard(a)winehq.org
On Jan 12, 2013, at 4:12 AM, Alexandre Julliard wrote:
Ken Thomases <ken(a)codeweavers.com> writes:
On Jan 11, 2013, at 11:13 AM, Alexandre Julliard wrote:
It doesn't seem to work when installed:
wine: failed to initialize: dlopen(/usr/local/lib/wine/ntdll.dll.so, 258): image not found
I assume you did indeed build it with the prefix /usr/local and there is a /usr/local/lib/wine/ntdll.dll.so. Is that right?
The prefix is /usr/local, but there are no files in there, I moved them somewhere else. That's the whole point, files are supposed to be found relative to the binary, not in the hardcoded prefix.
OK, but that still works for me. I configured with --prefix=$HOME/test1, I installed there, and tested. Then, I renamed ~/test1 to ~/test2 and retested and things still worked. (I'll also point out that none of the Wine library references incorporate absolute paths any more with my change. So, even working when installed in the configured prefix dir is an indication that it's successfully finding libwine relative to the binary. It has no other way to find it.) So, can you provide the output from those commands (as applied to the files wherever you've moved them)? Thanks, Ken
Ken Thomases <ken(a)codeweavers.com> writes:
OK, but that still works for me. I configured with --prefix=$HOME/test1, I installed there, and tested. Then, I renamed ~/test1 to ~/test2 and retested and things still worked.
(I'll also point out that none of the Wine library references incorporate absolute paths any more with my change. So, even working when installed in the configured prefix dir is an indication that it's successfully finding libwine relative to the binary. It has no other way to find it.)
So, can you provide the output from those commands (as applied to the files wherever you've moved them)?
Of course now that I'm trying to investigate it's working fine... I'll have to look into this some more on Monday. -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Ken Thomases