From: Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru>
To: Timothy Miller <tsm@cs.brown.edu>
Cc: ZSH Workers Mailing List <zsh-workers@sunsite.dk>
Subject: Re: AIX-problem: the main module won't link statically
Date: Tue, 12 Jun 2001 21:58:43 +0400 [thread overview]
Message-ID: <3B265853.3000108@mow.siemens.ru> (raw)
In-Reply-To: <yeh3d95lsa0.fsf@water.cs.brown.edu>
Timothy Miller wrote:
>
> No, autoconf doesn't exist on our aix machines, and I had no idea where
> autoheader came from or what it was part of, and presumed it was
> architecture-independent because it wasn't run as part of compiles of the
> regular distribution.
>
Both autoconf (and autoheader as its part) is needed only for developers
to produce configure. Then it is really not used anymore to actually
compile package.
>
> The second part of the patch didn't quite work on configure.in as the patch
> has
>
> elif test "$host_os" = cygwin; then
>
> where configure.in has
>
> elif test "x$ac_cv_cygwin" = xyes; then
>
> but other than that they're the same, so I applied that part by hand.
>
Yes, it was changed for autoconf-2.50 compatibility, sorry.
> ok, "CC=cc ./configure --prefix=/cs", manually running autoheader, make
> fails, log and other files included below.
That is almost perfect! Now we have to deal with usual AIX problems :-)
Two things:
cc -qlanglvl=ansi -s -o zsh main.o `cat stamp-modobjs` -bE:zsh.export
-ldl -lcurses -lm -lc
ld: 0711-319 WARNING: Exported symbol not defined: dputs
ld: 0711-319 WARNING: Exported symbol not defined: zpathmax
That is general problem. dputs is defined under DEBUG and zpathmax is
commmented out but they are marked as mod_export and our script does not
notice it. May be, we could pass the source file through cpp first
before generating export files.
cc -qlanglvl=ansi -c -I. -DHAVE_CONFIG_H -DMODULE -O -o zftp..o zftp.c
"zftp.c", line 1175.30: 1506-280 (E) Function argument assignment
between types
"unsigned long*" and "int*" is not allowed.
"zftp.c", line 1306.33: 1506-280 (E) Function argument assignment
between types
"unsigned long*" and "int*" is not allowed.
"zftp.c", line 2041.68: 1506-280 (E) Function argument assignment
between types
"unsigned long*" and "int*" is not allowed.
1500-030: (I) INFORMATION: zfgetmsg: Additional optimization may be
attained by recompiling and specifying MAXMEM option with a value
greater than 2048.
( echo '#!'; cat zftp.syms | sed -n '/^X/{s/^X//;p;}' | sort -u ) >
zftp.exportrm -f zftp.so
cc -qlanglvl=ansi -s -o zftp.so -bI:../../Src/zsh.export
-bE:zftp.export -emodentry zftp..o ../../Src/modentry..o -ldl -lcurses
-lm -lc
ld: 0711-317 ERROR: Undefined symbol: .handler
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
gmake[3]: *** [zftp.so] Error 8
gmake[3]: Leaving directory `/cs/src/zsh/zsh-4.0.1/Src/Modules'
gmake[2]: *** [modules] Error 1
gmake[2]: Leaving directory `/cs/src/zsh/zsh-4.0.1/Src'
gmake[1]: *** [modules] Error 2
gmake[1]: Leaving directory `/cs/src/zsh/zsh-4.0.1/Src'
gmake: *** [all] Error 1
Prototype errors are for getsockname(), accept(). Timothy, could you
send us header where these are declared?
I do not understand where this ``handler'' comes from; I do not see any
reference in zftp.c. Tomothy, could you run with suggested options
(-bnoquiet -bloadmap)? I guess, ``make DLLDFLAGS='-bnoquiet -bloadmap''
should do the trick.
Anyway, configure part is more or less clear; the only problem is GCC,
but to do something wihtout actual access to AIX is pretty hard.
-andrej
next parent reply other threads:[~2001-06-12 17:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.SV4.4.33.0106120954500.24714-200000@itsrm2.mow.siemens.ru>
[not found] ` <yeh3d95lsa0.fsf@water.cs.brown.edu>
2001-06-12 17:58 ` Andrej Borsenkow [this message]
2001-06-12 18:19 ` Peter Stephenson
2001-06-12 19:14 ` Bart Schaefer
2001-06-12 20:09 ` Wayne Davison
2001-06-13 9:20 ` Peter Stephenson
2001-06-13 6:09 ` 4.0.2 patches " Andrej Borsenkow
2001-06-13 9:22 ` Peter Stephenson
2001-06-13 8:46 ` Sven Wischnowsky
2001-06-13 8:48 ` Sven Wischnowsky
2001-06-13 6:34 ` General unqueue_signal problem Andrej Borsenkow
2001-06-13 9:30 ` Peter Stephenson
2001-06-18 7:21 ` Sven Wischnowsky
2001-06-18 9:20 ` Peter Stephenson
2001-06-13 10:57 ` Bart Schaefer
[not found] <001501c0eff2$70ad3ee0$21c9ca95@mow.siemens.ru>
2001-06-08 10:53 ` AIX-problem: the main module won't link statically Oliver Kiddle
2001-06-08 11:41 ` Andrej Borsenkow
2001-06-08 11:50 ` Timo Aaltonen
2001-06-08 12:05 ` Peter Stephenson
2001-06-08 12:06 ` Andrej Borsenkow
2001-06-08 12:11 ` Andrej Borsenkow
2001-06-08 12:28 ` Timo Aaltonen
2001-06-08 13:01 ` Andrej Borsenkow
2001-06-08 12:12 ` Timo Aaltonen
2001-06-08 14:23 ` Oliver Kiddle
2001-06-09 8:52 ` Andrej Borsenkow
2001-06-11 16:29 ` Timothy Miller
2001-06-11 17:58 ` Andrej Borsenkow
2001-06-12 12:24 ` Oliver Kiddle
2001-06-15 9:11 ` Timo Aaltonen
[not found] <Pine.LNX.4.10.10106081111000.23818-100000@nexus6.hut.fi>
2001-06-08 8:55 ` Andrej Borsenkow
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=3B265853.3000108@mow.siemens.ru \
--to=andrej.borsenkow@mow.siemens.ru \
--cc=tsm@cs.brown.edu \
--cc=zsh-workers@sunsite.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).