Mail Archives: cygwin/2014/10/24/15:37:11
--KM+e2hnYAO+MCJ5e
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
[Christian, please chime in]
On Oct 24 20:41, Denis Excoffier wrote:
> > 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:
> >>>=20
> >>> - 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.
> >>=20
> >> I use
> >> PATH=3D/my/dir/bin:/usr/bin /my/otherdir/myprog
> >>=20
> >> 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).
> >>=20
> >> 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.
> >>=20
> >> Also, i don't remember that the CWD has an impact on where DLL is foun=
d (apart
> >> from being in PATH, and apart from being the dir where the exe resides=
).
> >>=20
> >> 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.
> >>=20
> >> It seems to me that this change is a regression. Could someone please =
argue?
> >=20
> > 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=3D/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.
Sure. I was just pointing out that it's not a 100% stable method, but
dependent on the system's DLL search order, your CWD, and the fact that
the application is not installed into {/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.
If applications do this:
chdir("/path/of/DLLs");
dlopen("some.dll");
it wouldn't work anymore. It wouldn't work on Linux either, unless CWD
is in LD_LIBRARY_PATH or the default search path. This would work,
though:
chdir("/path/of/DLLs");
dlopen("/path/of/DLLs/some.dll");
Unfortunately the same doesn't work if the application calls execve
instead of dlopen because we can't add our LD_LIBRARY_PATH magic
there.
> > 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.
>=20
> Instead of adding the lookup of /usr/bin before the PATH, you could add
> it afterwards?
No. You don't expect this kind of flexibility in the Win32 API, do you?
The way it works is, there's a call SetDllDirectory which replaces the "."
in the DLL search path with the directory given as argument. The search
order is always this:
application dir
dir given in SetDllDirecory (Cygwin's bin)
system dirs
$PATH
> 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.
Not quite. LD_LIBRARY_PATH is only ignored if the excutable is a
suid/sgid executable. Unfortunately we don't have LD_LIBRARY_PATH at
all when running execve (but we have in dlopen).
> > 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'.
Yeah.
Sigh.
I don't like the idea either that this simple change breaks existing
scenarios. I'm inclined to revert this change.
Christian, would you mind terribly to re-add the tweak to postfix
to set $PATH?
Corinna
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--KM+e2hnYAO+MCJ5e
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJUSqpGAAoJEPU2Bp2uRE+g854QAJZ/E/iKxsCUNLg3J9d6vt5Z
u6FqxhpGh1ImOoELVHLQybBFAAZMsnpL8sFpfL6DCZczI9HNbiKfCgOusZJXk/pO
4lSX1GXgE0qjB0VGH0DsuaVP9cHEn+ykgAUvdZVcF6eXiRCZKXiSycSXpexjh7lm
IZsAhwFvYT40TckWLxrffo7vFoVn0pZlAje7/y4LjZcrkc5lN9xkHo8CdzowH75N
FE7TqBPO2oQoG+0effIvZh2Zzii+ADfMl1O2T2EJvmBH1EhqzKMCHkZEHgf4BAM6
w4pLfmJ61LHiRXk1i+dVYOw96+mdil7lAoPmSqLd9zM1JU2orGktPPw1UGELI8hY
vk6Q2F2zdpmlzM6X/3LJls8OG2m34pi//OMOG2O15jdjTOQdIFrtSE8jrPB1Q2tK
00/OViios7g3car9qH9JNFpYPlUZQ7D9rxAnCI+rCbGbl3EnS2vR4piUk9qaqRui
iZuLALr/1uHLNW0bzzZiCVky+yhSCNKAaZB92mHtRbmnnfC8ELjMItcU5JuPWehU
oMKEuYA0fx0mRjbT+5wXlo+kjYXIDUWTzKrHYzG8zfYyepCfe+oG2ODri4JPgfe8
XimIfGOnZqU1mavK1Mox2og7uhVT0gz/GZuk4bKW/e0LBaqULTyImK/JTAs+WRAe
XFTdvyZSkh25v6ydwYk/
=xNB1
-----END PGP SIGNATURE-----
--KM+e2hnYAO+MCJ5e--
- Raw text -