Mail Archives: cygwin/2014/10/10/11:39:46
--XaUbO9McV5wPQijU
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Oct 10 14:13, Arjen Markus wrote:
> 2014-10-10 13:22 GMT+02:00 <tednolan>:
> >>2014-10-10 13:24 GMT+02:00 Jan Nijtmans <...>:
> >>> 2014-10-10 12:34 GMT+02:00 Corinna Vinschen <...>:
> >>>> On Oct 9 11:46, tednolan.net wrote:
> >>>>> I'm pretty sure I've got some programs loading Tcl extensions that
> >>>>> cd into the directory with the extension dlls, load the extension a=
nd then
> >>>>> change back to where ever they were.
> >>>>
> >>>> Hmm. If so, it's quite a weird way to handle this, rather than
> >>>> loading the modules with full path.
> >>>>
> >>>> Is that a Tcl "feature", or is it how certain Tcl apps are implement=
ed?
> >>>> I can't really believe the former...
> >>>
> >>> This is certainly not a Tcl "feature"! The standard Tcl extension
> >>> mechanism always uses the full path simply because Tcl
> >>> cannot depend on platform-specific ways to search for
> >>> such libraries elsewhere.
> >>>
> >>> I'm willing to test this;I don't believe such a change
> >>> will break anything in my Tcl environment.
> >>>
> >>> Regards,
> >>> Jan Nijtmans
> >
> > Hmm,
> >
> > It's been a while, but I think it is something like the extension is
> > a DLL, but it depends on another DLL. Consider for instance, mysqltcl.
> > If you want to deploy that, you need the mysqltcl.dll and the mysql dll,
> > so you either have to be in the same dir when you load the extension,
> > or put that dir in PATH.
> >
> > Unfortunately, I can't run a test release on my work machine, or take
> > my work progs home.
>=20
> Right, that makes sense. There is indeed no way for the package
> manager to handle that scenario without external help, such as a PATH
> variable that includes the various directories these extra DLLs reside
> in.
There might be a potential workaround. Given that Cygwin Tcl calls
dlopen to load DLLs, we have this somewhat under control.
The default DLL search algorithm searches the application dir for
dependent DLLs. But there's a LoadLibraryEx flag called
LOAD_WITH_ALTERED_SEARCH_PATH. When using this flag, and the DLL is
given with full path, the application dir in the DLL search path is
replaced by the directory of the DLL. Thus, dependent DLLs will be
searched in the same dir the original DLL has been loaded from.
This could be utilized in dlopen. If the DLL is given with no path, and
if LoadLibrary failes, create the full path to the DLL and call
LoadLibraryEx (full_path, LOAD_WITH_ALTERED_SEARCH_PATH). DLLs in /bin
are taken care of by the SetDllDirectory call we're talking about here.
This is no 100% safe bet, I guess. It would fail to load DLLs in
scenarios where DLLs depend on other DLLs from the current dir as well
as from the application dir, and the application dir is not /bin. Just
how realistic is this scenario in a Cygwin environment?
Corinna
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--XaUbO9McV5wPQijU
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJUN/2tAAoJEPU2Bp2uRE+gVxsQAJgkEt2avpYxXvVpysGOycB8
EXTLg8Q2GZBgOFPDzYRVTXminLW4/OAmb0Prpjm3Ma57R7XaFsgepHqdLLtHvz+y
2BkSl0N/ng4RU1SqHm9z0h2LnE5SPk3dOqQHiUONc3xxMftvbBHd3K/fteCFZjGu
foVTQW4MD24qw1WCo2ij+y409OdZVtnoLYY6/DLi0kRxFVAtfXaKJzlO4m/7nRab
cNeZEF1m17K9d1WzvmUDTtOxgYwoxnNZJZHPf1ThsX/D857fKeVxAGk/IoOJtKDJ
ag/mXBjdSneX0FoPVkbApdGNwGWip2Fs5UwN79zb89R+AU+7EIjZTw5gKgDrQOp6
uib7e2LW5OqpSbq6Bjnfua9V9XtHoTl7OpFrEccCPs1TZOOTuv8OIEGTTmWGnd9A
WhxDYRNjnZcvZs+op5XFQsu+8Vdrp2rnpK7TaoQZsJ/ub9qdn5uGhNFMU/ZDU1B0
l90tu726Jvp6D5hcGnpjYdYnRubW+ljqK1eMGKfacPJPNoc5emVQb3X/6iKlhOuT
w/7FIvE2TFZ3rbPSzYLlITJPMNr+VMA8s1vx5pt7c4Dlv0RtXyRZAGDB6Q7NfKvq
6v5oyux/UVjyr+qN7+YtPvkUb5p3csxXngDSjpWLwcaIU7tdWl4VN0mJKGH2l3VO
NdbRb8NeS/581wePpOI8
=JzkY
-----END PGP SIGNATURE-----
--XaUbO9McV5wPQijU--
- Raw text -