zsh-workers
 help / color / mirror / code / Atom feed
From: Zoltan Hidvegi <hzoli@cs.elte.hu>
To: borsenkow.msk@sni.de
Cc: zsh-workers@math.gatech.edu (Zsh hacking and development)
Subject: Re: zsh-3.1.0-test3 release
Date: Wed, 20 Nov 1996 02:32:54 +0100 (MET)	[thread overview]
Message-ID: <199611200132.CAA00816@hzoli.ppp.cs.elte.hu> (raw)
In-Reply-To: <Pine.SV4.3.95.961118143422.35A-100000@itsrm1.mow.sni.de> from Andrej Borsenkow at "Nov 18, 96 02:41:34 pm"

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


  reply	other threads:[~1996-11-20  2:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-11-17  4:27 Zoltan Hidvegi
1996-11-17  7:29 ` Geoff Wing
1996-11-17  7:40   ` Geoff Wing
1996-11-17 16:44   ` Zoltan Hidvegi
1996-11-18 11:41 ` Andrej Borsenkow
1996-11-20  1:32   ` Zoltan Hidvegi [this message]
1996-11-19 10:24 ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199611200132.CAA00816@hzoli.ppp.cs.elte.hu \
    --to=hzoli@cs.elte.hu \
    --cc=borsenkow.msk@sni.de \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).