Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: loading dynamic modules in a static shell
- X-seq: zsh-users 7006
- From: Dan Nelson <dnelson@xxxxxxxxxxxxxxx>
- To: Vincent <zsh@xxxxxxxxxxx>
- Subject: Re: loading dynamic modules in a static shell
- Date: Mon, 19 Jan 2004 01:35:30 -0600
- Cc: Dominic Mitchell <dom@xxxxxxxxxxxxxxxx>, zsh-users@xxxxxxxxxx
- In-reply-to: <20040119052552.GA32753@xxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20040118121441.GA29157@xxxxxxxxxxxxxxxxx> <20040118153107.GA55970@xxxxxxxxxxxxxxxxxxxx> <20040119052552.GA32753@xxxxxxxxxxxxxxxxx>
In the last episode (Jan 18), Vincent said:
> On Sun, Jan 18, 2004 at 03:31:07PM +0000, Dominic Mitchell wrote:
> > On Sun, Jan 18, 2004 at 06:14:42AM -0600, Vincent wrote:
> > > Is it supposed to be possible to compile a static shell with part
> > > of the modules built in and to be able to load the remaining
> > > modules with zmodload?
> >
> > I think it depends upon the capabilities of the platform's dynamic
> > loader. Certainly for FreeBSD you won't be able to do this. This
> > is because all dynamic loading is disabled when a static binary is
> > used. For the current release (5.2) the root filesystem has been
> > made dynamic in order to get this working (for the nsswitch stuff
> > to work correctly).
>
> Thanks for the reply. I did not realize that. I could have sworn I
> remembered compiling programs before with mixed linking, where some
> libs I specified as "/usr/lib/xxx.a" while others were dynamic,
> specified with "-lxxx". Perhaps that was when I was running Linux.
You can do this, but note that this isn't a static binary; it's a
dynamic binary with some libraries loaded statically. You'll still
have a dependency on ld.so, and depending on which libraries you pulled
in statically, you may have issues dlopen'ing shared objects that also
depend on those libraries. Statically-linking a library only pulls in
the object files required for the link to complete, so if you link with
libc.a, you won't have all of libc in your executable. If your shared
object also depends on libc (most would, I guess), it will dlopen
libc.so, but now you will have two copies of some functions and
structures in libc, and constructors may fire twice.
I did some googling, and I don't think Linux or Solaris like dlopening
from static binaries, either.
--
Dan Nelson
dnelson@xxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author