Re: GnuTLS for W32

[Eli Zaretskii]

> From: Chong Yidong <address@hidden>
> Cc: Óscar Fuentes <address@hidden>,  address@hidden
> Date: Wed, 04 Jan 2012 14:48:22 +0800
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> From: Óscar Fuentes <address@hidden>
> >> Date: Tue, 03 Jan 2012 20:48:23 +0100
> >>
> >> If, at run time, you can find the elisp packages downloaded by
> >> package.el, what's the problem with finding a dll on the same directory
> >> (or a subdirectory of it, if you wish) ?
> >
> > Because load-path is used for loading Lisp, but not for loading DLLs.
> 
> The code in a Lisp package can extract its package directory from the
> variable `load-file-name'.  The Multi-file Packages node of the Lisp
> manual gives an example of this.

The issue is not figuring out the directory where the DLL lives.  The
issue is instructing the code that needs to load that DLL where to
look for it.

Currently, we load the DLLs by specifying their basename, without
leading directories, which causes the corresponding Windows API to
search for the DLL in known places, as documented in the MS
documentation.  To change that and give Lisp programs control of where
to look for DLLs, we need changes on the C level.

The other problem is how to upgrade a DLL from an Emacs session that
already uses the previous version of that DLL.  I think this is hard
without restarting Emacs, and not trivial even with restarting.

> I'm not saying we should distribute GnuTLS support via ELPA, only that
> the Package system is no technical barrier.

The barrier I was talking about has nothing to do with package.el.