From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6849 invoked from network); 14 Sep 2000 17:16:23 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Sep 2000 17:16:23 -0000 Received: (qmail 6320 invoked by alias); 14 Sep 2000 17:15:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12807 Received: (qmail 6313 invoked from network); 14 Sep 2000 17:15:40 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer david.siemens.de) From: "Andrej Borsenkow" To: Subject: RE: Module hierarchies, aliasing, and dependencies Date: Thu, 14 Sep 2000 21:15:37 +0400 Message-ID: <005201c01e6f$6696b5d0$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <1000914163650.ZM12492@candle.brasslantern.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > > 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