About the dll search algorithm of dlopen (patch-r3)

[Corinna Vinschen]

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?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20160826/85ec1408/attachment.sig>