Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
RE: Module hierarchies, aliasing, and dependencies
- X-seq: zsh-workers 12807
- From: "Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>
- To: <zsh-workers@xxxxxxxxxxxxxx>
- Subject: RE: Module hierarchies, aliasing, and dependencies
- Date: Thu, 14 Sep 2000 21:15:37 +0400
- Importance: Normal
- In-reply-to: <1000914163650.ZM12492@xxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
>
> It *was* my assumption that the file name relative to $module_path would
> be the single argument to zmodload when loading the module, but of course
> there's no particular reason to assume that, either.
>
> } zmodload -f /path/to/my/module.so zsh/zle
>
> That would be fine, except that it requires you to know the full path
> to the module and the shared object extension, so it won't work in a
> cross-platform way. How about instead something like
>
It depends on usage pattern. I think about it as developers aid in the first
place. In this case you definitely know path name and extension :-)
But nothing prevents relative pathnames like
zmodload -f relative/path zsh/zle
that would be interpreted in usual way (search through module_path adding
system-specific extension).
>
> I suggest that, for the first pass, the "module identification" can be
> limited to the base name of the shared object; unless I misunderstand
> what you said about Windows DLLs, it won't work to load two DLLs with
> the same base name anyway (at least not without a major rewrite, and
> maybe not even then).
>
The worst case is that currently even zsh/foo and bar/foo may clash. But this
happens to my best knowledge only if we use implicit linking (I believe,
Microsoft calls it compile-time). We can load two DLLs with the same base
names using dlopen() and dlsym() will work correctly. IIRC :-) I must check.
What may not work, if zsh/bar depends on (is linked with) zsh/foo and my/bar
depends on my/foo. I am afraid, that Windows will search only one of */foo
DLLs even if we explicitly load both.
-andrej
Messages sorted by:
Reverse Date,
Date,
Thread,
Author