From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-request@euclid.skiles.gatech.edu Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by coral.primenet.com.au (8.7.6/8.7.3) with ESMTP id NAA09592 for ; Wed, 20 Nov 1996 13:05:09 +1100 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id UAA19504; Tue, 19 Nov 1996 20:45:35 -0500 (EST) Resent-Date: Tue, 19 Nov 1996 20:45:35 -0500 (EST) From: Zoltan Hidvegi Message-Id: <199611200132.CAA00816@hzoli.ppp.cs.elte.hu> Subject: Re: zsh-3.1.0-test3 release To: borsenkow.msk@sni.de Date: Wed, 20 Nov 1996 02:32:54 +0100 (MET) Cc: zsh-workers@math.gatech.edu (Zsh hacking and development) In-Reply-To: from Andrej Borsenkow at "Nov 18, 96 02:41:34 pm" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Ms9_R3.0.gm4.-Acao"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2435 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Andrej Borsenkow wrote: > > It may now support dynamic loading on SVR4 systems. Try it. If it does not > > work, send a patch to fix it. > > > > Yes, it works. There is a small problem in linking libzsh.so - I have to > think it over. In short: > zsh is linked with -ltermcap. But now termcap functions are used in > libzsh.so and not in zsh. If termcap is static (and we have only static > version), it is not used when linking, and I get run-time error when > accessing termcap functions. > > Probably, we need to split LIBS between those neede for zsh itself (does > it need any at all?) and libzsh.so. As the whole code is now in libzsh.so, > probably it is enough: > > zsh: $(PROTO) $(ANSI@U@KNR) $(@L@IBZSH) $(@L@OBJS) > $(LINK) $(@L@OBJS) -lzsh > > $(LIBZSH): $(LIBOBJS) > $(DLLD) $(LDFLAGS) $(DLLDFLAGS) -o $(LIBZSH) $(LIBOBJS) $(LIBS) > ln -sf $(LIBZSH) libzsh.so > > where libs doesn't include -lzsh? I'm afraid it's a bit more difficult problem. Of course executable part which is main.c only does not need any library other than libzsh. So if -ltermcap is not dynamic it must be linked to libzsh. But is it really possible? Dynamic libs usually need -fpic (btw. zsh is quite big, maybe this should be -fPIC instead) and if termcap is not dynamic it was probably compiled without -fpic. On some architectures every code is position independent so -fpic is not necessary. With some binary formats libraries do not have to be position independent. If one can use a termcap lib linked to the dynamic libzsh one can also make a dummy dynamic library linked with termcap which can then be used instead of the missing libtermcap.so dynamic lib. Alternatively everyone who can compile zsh can also compile GNU termcap or ncurses dynamically (with that I'm just saying that it is a very silly thing from an OS vendor not providing dynamic termcap, it just encourage its users not to use its product). On elf systems a shared library may seem to work even without -fpic since the dynamic loader can relocate the code but such a library will not be shared since the relocation will change the text section. > BTW it would be nice to be able to compile static as well as dynamic > version of zsh from te same Makefile. Do you mean without recompiling everything? There are some conditional compilation in the source which means that everything has to be recompiled. You can always build multiple versions using separate build directories (the build directory is always the directory from where you issued configure). This way you can buld static and dynamic versions or multi-architecture versions without duplicating the code. I use that feature regularily building optimized zsh for everyday use and an other version for debugging without optimization and with all sorts of internal debugging enabled. Zoltan