From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29536 invoked by alias); 30 Aug 2016 13:35:15 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 28756 invoked by uid 89); 30 Aug 2016 13:35:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-101.6 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=CMD, yuk, Easy, consent X-HELO: drew.franken.de Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Aug 2016 13:35:13 +0000 Received: from aqua.hirmke.de (aquarius.franken.de [193.175.24.89]) (Authenticated sender: aquarius) by mail-n.franken.de (Postfix) with ESMTPSA id 11E40721E281A for ; Tue, 30 Aug 2016 15:35:09 +0200 (CEST) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id 694EF5E0418 for ; Tue, 30 Aug 2016 15:35:08 +0200 (CEST) Received: by calimero.vinschen.de (Postfix, from userid 500) id 5BFE2A8059E; Tue, 30 Aug 2016 15:35:08 +0200 (CEST) Date: Tue, 30 Aug 2016 13:35:00 -0000 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: About the dll search algorithm of dlopen (patch-r3) Message-ID: <20160830133508.GE23664@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <20160601201748.GI11431@calimero.vinschen.de> <57B735D5.4070401@ssi-schaefer.com> <57B7362D.8060707@ssi-schaefer.com> <20160820193243.vbmpfjc5mjdhrndh@calimero.vinschen.de> <4d4481ce-c163-0ec9-29f5-59bbe13260fa@ssi-schaefer.com> <0963e74e-c963-a7f4-19e7-490b02f9393e@ssi-schaefer.com> <20160822183710.GA26590@calimero.vinschen.de> <025fabf1-e22c-246c-c3d6-3d2e5560ae39@ssi-schaefer.com> <20160826120438.GT9783@calimero.vinschen.de> <04f03674-3382-e2d7-723c-b57730f14361@ssi-schaefer.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jL2BoiuKMElzg3CS" Content-Disposition: inline In-Reply-To: <04f03674-3382-e2d7-723c-b57730f14361@ssi-schaefer.com> User-Agent: Mutt/1.6.2 (2016-07-01) X-SW-Source: 2016-08/txt/msg00020.txt.bz2 --jL2BoiuKMElzg3CS Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2584 On Aug 29 11:24, Michael Haubenwallner wrote: > Hi Corinna, >=20 > 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 becau= se > >>> otherwise we had trouble starting Cygwin from CMD or the Explorer > >>> GUI "Run..." box. We can't change this without breaking everythi= ng > >>> since we *do* depend on the Windows loader yet. > >>>=20=20=20=20=20 > >>> 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 consen= t? > >>> Or, FWIW, the user's consent in case of LD_LIBRARY_PATH? > >> > >> 've split into add_lib_searchdir (), used for "/usr/lib" only. > >=20 > > Btw., I just noticed something interesting, independently of your patch. > > Consider the file /usr/bin/cygz.dll: > >=20 > > - dlopen (libz.so) success > >=20 > > - dlopen (/usr/bin/libz.so) success > >=20 > > - dlopen (/usr/lib/libz.so) fails > >=20 > > 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? >=20 > 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 > /bin (because of the missing Cygwin loader). You have a point there. > 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. It feels certainly more safe to restrict this to the system path for now. But... yeah, you have a point. Not well thought out, just an idea kicking around: Apart from the obvious system path handling, what if other lib->bin transitions only take place if the calling application is installed in that very bin dir...? Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --jL2BoiuKMElzg3CS Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXxYuMAAoJEPU2Bp2uRE+gOGYP/RQeTQnqdTqcPQrQgrkfhhV+ wnK6MczoP+Cmzs5OKtZwUOMumYHH5L+rcxN8cFJK4wKgTZAa4OEuK+oKj2DEDLsd l25olKB4p4+ROGhiGV2CYAxbL4UcsPC26/KFvMxNNyPv5HkjtaV1yEa96PYKQGtl pibVthwHsGWV2yhTEYWMyTkoGz5v41lK/P/dA/K7o7fN7ztF64sA34J5vk/KwZo5 53Tqonru2eXWQk4a63G9oUZX97IaDxLUcumPK3OYsxMlzci+hwEkFr8BsiIHmILB KNKzUyUQFRkb7MIwR0ZvIpF9a6a5YVZYybp/PKpi0ixFYnsBH62cTLiEDDlncNd/ ngcHdd0ndC1OXFqyeVzDOvoQMyaDvq/OcN3gzlSBExNtyeelJRZn4MwTyVHWpe9J 8bS3giWYHDvFKwtK+RoHgypc3Y0+m/4XvbEYLGkhn7Kaw5G5OwdXTF/Ol0VzvDig O8seC/SV7+GW2vkHr2fxvyg++lWj2JVHq/ChKUK08l2IttIeGXMQ3gaVZngPaQIk UEf7jLam2Ax45BOUCQdmXVT0zq//qEgPwCgUiVB07tYK9NDEnQECncnhWw6EOiSE KI83noGQHrKMs4nBUYIl2spEQpaGYAL2wfS/ZbNg8tP3uOmBxNxCgaYeJm7OUer4 Y9UPIE9+vlD1GP9qXQ3V =0u/G -----END PGP SIGNATURE----- --jL2BoiuKMElzg3CS--