Ove Kaaven wrote:
> There has been some reports on the newsgroup like
>
> err:module:BUILTIN32_dlopen failed to load libver.so: liblz32.so: cannot open shared
>object file: No such file or directory
>
> with mention of libraries residing in /usr/lib/wine, and /usr/lib/wine
> configured as EXTRA_LD_LIBRARY_PATH. What I think happens here, is that
> the app wants ver.dll, Wine loads it with BUILTIN32_dlopen(), which calls
> ELFDLL_dlopen(). Since /usr/lib/wine isn't in ld.so.conf, ELFDLL_dlopen()
> searches the EXTRA_LD_LIBRARY_PATH for libver.so, finds it, and tries to
> load it with dlopen() using the explicit path.
>
> But then libver.so depends on liblz32.so, but that's not in ld.so.conf
> path either, and this time, ELFDLL_dlopen() can't help since it doesn't
> get called recursively by dlopen() or anything...
>
> Something should probably be done to fix this...
This is exactly the problem that I have described over a year ago which
never ever must occur: .so dlls, regardless of the encapsulation, cannot
reference eachother on the ELF linkage level.
I just did a "ldd *.so" in the dlls directory and many libraries have
this problem. The makefiles do this and are the problem of missing
import tables (I'll hope to get the elfdlls going again soon).
The best solution at the moment is to set LD_LIBRARY_PATH to point to
the dlls directory. I normally set it to:
$ export LD_LIBRARY_PATH=/home/wine/cvs:/home/wine/cvs/dlls
(I normally don't install wine, so I need this all the time)
Those who install wine must have /usr/local/lib in their ld.so.conf (and
rerun ldconfig), or set LD_LIBRARY_PATH to point to there.
Greetings Bertho
