[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

Denis Excoffier cygwin@Denis-Excoffier.org
Fri Oct 24 18:41:00 GMT 2014


> 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



More information about the Cygwin mailing list