This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: About the dll search algorithm of dlopen (patch-r3)
Hi Corinna,
On 08/26/2016 02:04 PM, Corinna Vinschen wrote:
> On Aug 25 19:48, Michael Haubenwallner wrote:
>> On 08/22/2016 08:37 PM, Corinna Vinschen wrote:
>>> (*) Yuk! Do we really, *really* want that? The redirection from
>>> /usr/lib to /usr/bin is only done for system libs, and only because
>>> otherwise we had trouble starting Cygwin from CMD or the Explorer
>>> GUI "Run..." box. We can't change this without breaking everything
>>> since we *do* depend on the Windows loader yet.
>>>
>>> However, as long as this is restricted to /usr/lib, /usr/bin, it's a
>>> closed system under control of "the distro". If you extend this to
>>> *any* external path ending in "lib", isn't it inherently dangerous
>>> to automate this under the hood, without the application's consent?
>>> Or, FWIW, the user's consent in case of LD_LIBRARY_PATH?
>>
>> 've split into add_lib_searchdir (), used for "/usr/lib" only.
>
> Btw., I just noticed something interesting, independently of your patch.
> Consider the file /usr/bin/cygz.dll:
>
> - dlopen (libz.so) success
>
> - dlopen (/usr/bin/libz.so) success
>
> - dlopen (/usr/lib/libz.so) fails
>
> That's pretty clear when looking through the code, but... wouldn't
> it make sense to allow that? If a path is given, and the path points
> to /usr/lib, search the file in /usr/bin as well?
Easy enough - but this should apply to any prefix IMO: While the
application specific prefix often isn't /usr - but something like
/usr/local or /opt/application, application specific libs may be
built & installed with libtool or something similar as well - at
least some tool that knows about installing the real dll into
<app-prefix>/bin (because of the missing Cygwin loader).
But agreed, it makes sense doing /lib->/bin for the explicit path and
the /usr/lib default only and not for the environment-provided paths.
/haubi/