zsh-workers
 help / color / mirror / code / Atom feed
From: Andrew Main <zefram@tao.co.uk>
To: hzoli@cs.elte.hu (Zoltan Hidvegi)
Cc: zsh-workers@math.gatech.edu
Subject: Re: PATCH: dynamic loading on AIX
Date: Wed, 6 May 1998 09:55:08 +0100 (BST)	[thread overview]
Message-ID: <199805060855.JAA20210@taos.demon.co.uk> (raw)
In-Reply-To: <199805060646.BAA02655@hzoli.home> from "Zoltan Hidvegi" at May 6, 98 01:46:14 am

Zoltan Hidvegi wrote:
>The patch below implements dynamic loading on AIX.  AIX 4.1 and older
>versions do not support the dlopen/dlsym interface.  Instead each object
>has an export and an import list.  The export list contains the list of
>symbols which is provided by the object for use by subsequently loaded
>dynamic modules.

This is interesting.  I've been planning for some time to do a manual
implementation of symbol tables, much like this, to allow dependent module
loading on systems such as SunOS, where symbols from one loaded module
are not available to other modules.  Presumably much of the export list
handling code can be shared between these two uses.

Probably we could also use the export list to reduce the size of
symbol tables on some systems where the symbols are handled completely
automatically.

>The setterm, refresh and cs external symbols had a conflict with the AIX
>C library or with the curses library so they were renamed to zsetterm,
>zrefresh and zshcs respectively.  `cs' was not changes in the source
>files, instead cs is #defined to zshcs in system.h.  It also #defined ll
>just for consistency, since cs and ll are usually used together.  I chose
>the #define solution since cs is used too many places.

I'd like to do a proper solution to this sort of problem.  I've been
thinking along the lines of automatically #defineing each symbol `foo'
to `name_of_module__foo', thus avoiding clashes with both the C library
and other modules.

>                                             It is possible to
>autogenerate export files from the .pro files, and I do have a script
>which does that, but that creates an export file with 636 symbols for zsh
>and 282 symbols for zle, which the current modules use only 233 symbols
>from zsh.export and 8 symbols from zle.export.  Making the export list
>smaller speeds up loading, reduces memory usage and reduces the risk or
>name collisions.

Perhaps it would be better to add a dummy keyword to the declarations,
to flag symbols for export from the module.

-zefram


  reply	other threads:[~1998-05-06  9:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-05-06  6:46 Zoltan Hidvegi
1998-05-06  8:55 ` Andrew Main [this message]
1998-05-08 12:59 ` PATCH: more " pws
1998-05-08 13:37   ` Peter Stephenson
1998-05-08 15:10   ` hzoli

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=199805060855.JAA20210@taos.demon.co.uk \
    --to=zefram@tao.co.uk \
    --cc=hzoli@cs.elte.hu \
    --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).