On 27 Sep 2000, Alexandre Julliard wrote:
> At the moment we have the problem that dlls import one another at the
> ELF level, which is why they have to be installed in the same
> directory and with the same rpath as libwine.so.
That was what my solution of setting the rpath to $(prefix)/lib/wine was
supposed to solve. Binary packagers tend to *not* install the dlls into
the same path as libwine.so right now... while libwine.so is in a standard
path and does not need rpath.
> But once import tables are working, dlls will only import each other
> through an explicit dlopen using EXTRA_LD_LIBRARY_PATH.
Fine, but how long until that? Should be possible to have a workaround
(rpath) that packagers can understand until then...
> Basically the final situation should be:
>
> - libwine.so and libwine_unicode.so in $(prefix)/lib
This is a standard place in all current packaging, so it generally doesn't
need a rpath.
> - all dlls .so in $(prefix)/lib/wine
> - rpath set to $(prefix)/lib
> - EXTRA_LD_LIBRARY_PATH set to $(prefix)/lib/wine
The only thing that I've proposed different from this is rpath set to
$(prefix)/lib/wine in the .so files that are installed there, so they can
find their dependencies for now. Which is what my suggested patch to
wine-devel does. The only issue was that it hardcoded "lib/wine" instead
of being configurable, but if you think it should be like that, perhaps it
could be accepted like it was?
