On Mon, 19 Jun 2000, Bertho Stultiens wrote:
> BUILTIN_dlopen("target.dll", ...)
> {
> ...
> ELF_do_dlopen("libtarget.so", RTLD_LAZY|RTLD_GLOBAL);
> ...
> }
>
> ELFDLL_dlopen("target.dll", ...)
> {
> ...
> ELF_do_dlopen("target.so", RTLD_NOW);
> ...
> }
>
> Where ELF_do_dlopen() will search the EXTRA_LD_LIBRARY_PATH for you.
Isn't this almost the case? If not quite, then close enough to make it
possible to easily do it when/if it becomes necessary.
> I am not saying that they are opposites, but merely that you should be
> extremely cautious. That is why I suggest to split that part. Elflls
> should fail immediately if the dependencies are not resolved to ensure
> isolation. Moreover, they cannot have the RTLD_GLOBAL flag set because
> they possibly share identical symbols with different meaning/destination
> (you cannot use ELF-linking against elfdlls).
Well, whatever... but I am more inclined towards Alexandre's approach.
> Removing the dependencies does not necessarily imply RTLD_LAZY. This can
> be prevented if the target is linked against the dependent .so-libraries
> *and* they are in the LD_LIBRARY_PATH or ld.so.conf. I prefer to set
> LD_LIBRARY_PATH prior to wine startup to make sure that I can load the
> dependencies. This scenario does not require RTLD_LAZY.
That's not "removing the dependencies" at all. And isn't the whole point
of EXTRA_LD_LIBRARY_PATH so you wouldn't need LD_LIBRARY_PATH or changing
ld.so.conf? So that clean RPMs and DEBs can be built that places the libs
in a separate directory without needing the user to change anything?
I think I'll just submit the patch...
