zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@u.genie.co.uk>
To: Zsh workers <zsh-workers@sunsite.auc.dk>
Subject: Re: PATCH: completion
Date: Tue, 26 Oct 1999 14:01:27 +0100	[thread overview]
Message-ID: <3815A627.19C7F2A@u.genie.co.uk> (raw)

Sven wrote:
> Then one question for the AIX users: I still don't know what the
> `*.export' files are for and what exactly has to go into them, so I
> haven't tried to build or change them. Btw. the `comp1.mdd' contained
> `hasexport=1' which, I think, may have to do with that, but I couldn't 
> find any documentation for it. I have added it to `complete.mdd'
> anyway.

My understanding is that the export files list symbols which are to be
resolved
at runtime instead of link-time. It seems to use this to link, for
example
computil.so with symbols from compctl.so where on other systems, it
would look
in compctl.so to get them.

When the next pws/bart release arrives, I'll sort out the .export files
if
necessary and send a patch. The following might help explain what the
files are:

The errors I was getting from the C compiler were roughly as follows:

        /bin/cc -qlanglvl=ansi  -s  -o computil.so
-bI:../../Src/Zle/compctl.exp
ort -bI:../../Src/Zle/zle.export -bI:../../Src/zsh.export  -emodentry
computil..
o  ../../Src/modentry..o -lcurses -lm -lc 
0706-317 ERROR: Unresolved or undefined symbols detected:
                 Symbols in error (followed by references) are
                 dumped to the load map.
                 The -bloadmap:<filename> option will create a load map.
incompfunc
compwords
compcurrent
.ignore_suffix
compprefix
compsuffix
.restrict_range
.ignore_prefix
.set_list_array
.get_user_var
make: 1254-004 The error code from the last command is 8.

Note that all the .o files have two dots (e.g. modentry..o) when
building on
AIX. This is probably a mistake somewhere but it has always compiled
happily so
I've never bothered.

I've cut out the relevant parts of the ld man page here. I can send you
the
whole thing if you want.

  Imports lists identify which external symbols are to be resolved
  during run time, instead of being resolved during the linkage ed-
  itor  process.   The import list generally identifies the execut-
  able object file  that contains the definition of the import sym-
  bol, so the loader can find  and resolve that symbol at run time.
  The information needed to resolve import  references  is found in
  one of two places:
  
  *     The loader section of shared object files
  
  *     Files whose first record begins with the #! (pound sign and
  exclamation point) that contain a list of external symbols. These
  files are called import lists.
  
  Export lists identify external symbols that are to be made avail-
  able for another executable object file to import.  The file for-
  mat of an export list is the same as the file format of an import
  list.
----
  -bOption      Sets binder (ld) special control and processing options.
  See the following section on  binder options.  This flag can be
  repeated.
----
  import:FileID or I(the uppercase letter i):FileID     The binder im-
  ports the external symbols specified in the FileID variable.
  There is no default import file.


             reply	other threads:[~1999-10-26 13:01 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-26 13:01 Oliver Kiddle [this message]
1999-10-26 13:35 ` Zefram
  -- strict thread matches above, loose matches on Subject: below --
2000-02-21  9:50 Sven Wischnowsky
1999-10-28  8:12 Sven Wischnowsky
1999-10-28  6:58 Sven Wischnowsky
1999-10-27  8:42 Sven Wischnowsky
1999-10-27 16:39 ` Bart Schaefer
1999-10-27  7:14 Sven Wischnowsky
1999-10-27 21:26 ` Tanaka Akira
1999-10-26 13:17 Sven Wischnowsky
1999-10-26 11:03 Sven Wischnowsky
1999-10-26 17:17 ` Bart Schaefer
1999-10-26 17:22 ` Tanaka Akira
1999-10-26 17:32   ` Tanaka Akira
1999-08-30  9:30 Sven Wischnowsky
1999-08-27  7:03 Sven Wischnowsky
1999-08-27  8:29 ` Tanaka Akira
1999-08-28  6:01   ` Tanaka Akira
1999-08-26 13:52 Sven Wischnowsky
1999-08-26 12:20 Sven Wischnowsky
1999-08-26 13:17 ` Tanaka Akira
1999-08-26 17:56 ` Tanaka Akira
1999-08-25 12:57 Sven Wischnowsky
1999-08-25 12:54 Sven Wischnowsky
1999-08-25  8:24 Sven Wischnowsky
1999-08-26 10:54 ` Tanaka Akira
1999-08-24 10:43 Sven Wischnowsky
1999-08-25  1:56 ` Tanaka Akira
1999-08-24  9:12 Sven Wischnowsky
1999-08-24 10:04 ` Tanaka Akira
1999-08-23 13:46 Sven Wischnowsky
1999-08-23 16:16 ` Tanaka Akira
1999-08-24 15:56 ` Tanaka Akira
1999-08-23 12:00 Sven Wischnowsky
1999-08-23  9:32 Sven Wischnowsky
1999-08-23 10:54 ` Tanaka Akira
1999-08-20 12:59 Sven Wischnowsky
1999-08-20 23:22 ` Tanaka Akira
1999-08-21  8:39   ` Tanaka Akira
1999-08-21 17:47     ` Tanaka Akira
1999-08-20  7:42 Sven Wischnowsky
1999-08-19 13:59 Sven Wischnowsky
1999-08-19 10:44 Sven Wischnowsky
1999-08-19 14:38 ` Tanaka Akira
1999-08-24 13:46 ` Peter Stephenson

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=3815A627.19C7F2A@u.genie.co.uk \
    --to=opk@u.genie.co.uk \
    --cc=zsh-workers@sunsite.auc.dk \
    /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).