X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id :references:to; q=dns; s=default; b=VKrpozI2YJdLodZ84GiuLRIJjJEF PvrC4MI2CL2hCIDu1m55VbowL9AcUJ+P5bdbeNM1hvjv4KjiFmzH9T+qzG5vsYHW d9SmXhuNnoUeLSR1y50mYvzgVEwqk+ckje9hI1ECvIHU3VHQW51jsoaG3Wvr+4Pa 7ssoZVNIW/pGVzk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id :references:to; s=default; bh=MI7dguyx2WUsKdGOL9egcb7Ph+s=; b=bP ELhGIgDI+nLptfboGCWLaO7XQ5Ep0PHLv56l1+fuclL1P3ZovfF4JkxEp28aF6nd ihSggxxUiGHstRIRzAyraYc1wE9y58PllwKcb3x6sMKXj2FDTaXXhLRneG5ujf7q a0pu43PlTdVFLUKJ+RXEPMernd4x1LQHBWrI3tWdA= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: smtp5-g21.free.fr Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 $1990.1$) Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1 From: Denis Excoffier In-Reply-To: <20141024110209.GJ20607@calimero.vinschen.de> Date: Fri, 24 Oct 2014 20:41:16 +0200 Message-Id: <25D5C8B8-57B7-449C-95C6-CD9055816B6B@Denis-Excoffier.org> References:

<20141024110209 DOT GJ20607 AT calimero DOT vinschen DOT de> To: cygwin AT cygwin DOT com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id s9OIfkgv026597 > On 2014-10-24 13:02, Corinna Vinschen wrote: > > On Oct 23 20:06, Denis Excoffier wrote: >> On 2014-10-22 11:23, Corinna Vinschen wrote: >>> >>> - Drop the current working directory from the default DLL search path in >>> favor of Cygwin's /bin dir. >> I'm not so comfortable with this one. >> >> I use >> PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog >> >> There is no DLL at all in /my/otherdir (this is the very first place >> for Windows to look for DLL's, and i think that this cannot change). >> In /my/dir/bin, there is an updated version of a library also >> located in /usr/bin, for example an updated cygstdc++-6.dll (from GCC 4.9.1). >> >> Does this mean that, under this change, cygstdc++-6.dll will be found >> in /usr/bin and not in /my/dir/bin ? In fact, this is what i can >> observe personnally. >> >> Also, i don't remember that the CWD has an impact on where DLL is found (apart >> from being in PATH, and apart from being the dir where the exe resides). >> >> For a test i have commented out in cygheap.cc the line >> 'wcpncpy (installation_dir, ...' (and also the next one) >> and the old behaviour is now back. >> >> It seems to me that this change is a regression. Could someone please argue? > > Hmm. It's hard to do the right thing here, I guess. I can see how > this is a regression in your scenario. OTOH, your scenario is not > stable. The directories in $PATH are the last ones in the DLL search > order. So, your scenario already wouldn't work if your CWD is /bin > (or /usr/bin). Typically, the line 'PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog' is in a Makefile, as part of some 'make check'. I don't usually build from /usr/bin. I was not aware that CWD was useful. IIUC, your change removes the lookup into CWD (and replaces with a lookup to somewhere else). Who needs CWD at the first place? These people (or specification?) will not be OK now. > > From Cygwin's POV {/usr}/bin is a system dir. For security reasons it > makes sense that the system DLLs in /bin cannot be overridden, unless > it's an installation issue which should be covered by looking into the > application installation dir first. Instead of adding the lookup of /usr/bin before the PATH, you could add it afterwards? Or do you mean that my use is bad practice for security reasons? That there might be some unexpected DLL somewhere in the PATH? IIRC, in linux/solaris, LD_LIBRARY_PATH is not honored when you are root, not otherwise. > > Having said that, moving your DLLs into the application dir is really > not an option? Oh yes, i use it all the time. It is the job of 'make install' to also install the appropriate DLLs. The point here is for 'make check'. > > Does anybody else have a similar scenario to cover, which doesn't work > anymore with this change? Yes please? Regards, Denis Excoffier. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple