Re: AIX-problem: the main module won't link statically

Re: AIX-problem: the main module won't link statically

[Andrej Borsenkow]

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

Re: AIX-problem: the main module won't link statically

[Peter Stephenson]

Andrej Borsenkow wrote:
> 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.

I'm pretty sure the last time I used AIX almost two years ago this wasn't a
problem.  Certainly the arguments were different but I don't think there
were any other problems.

I may have simply forgotten, but I certainly used gcc/g++ for a lot of
other things on AIX and I probably would remember if something was
seriously wrong.  Can't find anything in the mailing list archive
indicating which I was using.

If this version of AIX can be tricked into working even only with cc, I
will release the result as 4.0.2.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: AIX-problem: the main module won't link statically

[Bart Schaefer]

On Jun 12,  7:19pm, Peter Stephenson wrote:
> 
> If this version of AIX can be tricked into working even only with cc, I
> will release the result as 4.0.2.

Are there other changes that should go into 4.0.2 but haven't yet?

In particular, 14578, 14796, and 14824.

Re: AIX-problem: the main module won't link statically

[Wayne Davison]

On Tue, 12 Jun 2001, Bart Schaefer wrote:
> Are there other changes that should go into 4.0.2 but haven't yet?

Yes, 14793 should definitely go in, and I've been ready to commit it to
the branch, but I got no response to my email saying "go".

..wayne..

4.0.2 patches RE: AIX-problem: the main module won't link statically

[Andrej Borsenkow]

> On Jun 12,  7:19pm, Peter Stephenson wrote:
> > 
> > If this version of AIX can be tricked into working even only with cc, I
> > will release the result as 4.0.2.
> 
> Are there other changes that should go into 4.0.2 but haven't yet?
> 
> In particular, 14578, 14796, and 14824.
> 

14766? I really hate to see 'ttypts/3' in my prompt on Mandrake :-) 

-andrej

General unqueue_signal problem

[Andrej Borsenkow]

> 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

This comes from unqueue_signals() macro. This macro directly calls handler()
from signals.c (at least, I presume it is this one). But as I understand,
zftp.c sometimes install its own handler. Any other module may possible
install own handler as well.

I do not understand how signal queuing works - anybody cares to check it? It
is trivial to add mod_export to handler deinition - but I do not like it. At
least, we should change the name then. handler is too cute for a globally
visible function.

-andrej

Re: AIX-problem: the main module won't link statically

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 12,  7:19pm, Peter Stephenson wrote:
> > 
> > If this version of AIX can be tricked into working even only with cc, I
> > will release the result as 4.0.2.
> 
> Are there other changes that should go into 4.0.2 but haven't yet?
> 
> In particular, 14578, 14796, and 14824.

You decide.

14841 isn't applied to the 4.0 branch either. Has anyone found any
problems with this? (It fixes a real -- and somewhat ugly -- bug.)


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: AIX-problem: the main module won't link statically

[Sven Wischnowsky]

I wrote:

> Bart Schaefer wrote:
> 
> > On Jun 12,  7:19pm, Peter Stephenson wrote:
> > > 
> > > If this version of AIX can be tricked into working even only with cc, I
> > > will release the result as 4.0.2.
> > 
> > Are there other changes that should go into 4.0.2 but haven't yet?
> > 
> > In particular, 14578, 14796, and 14824.
> 
> You decide.
> 
> 14841 isn't applied to the 4.0 branch either. Has anyone found any
> problems with this? (It fixes a real -- and somewhat ugly -- bug.)

Argh, sorry, sent that to early...

Two other things: the segv report from 14862 which I hope to get fixed
today should go in and if we can't figure out what's happening on Irix
(the job-suspend thing) we should probably add a remark to Etc/BUGS.


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: AIX-problem: the main module won't link statically

[Peter Stephenson]

Wayne Davison wrote:
> On Tue, 12 Jun 2001, Bart Schaefer wrote:
> > Are there other changes that should go into 4.0.2 but haven't yet?
> 
> Yes, 14793 should definitely go in, and I've been ready to commit it to
> the branch, but I got no response to my email saying "go".

That's fine by me.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: 4.0.2 patches RE: AIX-problem: the main module won't link statically

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> 14766? I really hate to see 'ttypts/3' in my prompt on Mandrake :-) 

That's harmless, that can go in.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: General unqueue_signal problem

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> > 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
> 
> This comes from unqueue_signals() macro. This macro directly calls handler()
> from signals.c (at least, I presume it is this one). But as I understand,
> zftp.c sometimes install its own handler. Any other module may possible
> install own handler as well.
> 
> I do not understand how signal queuing works - anybody cares to check it? It
> is trivial to add mod_export to handler deinition - but I do not like it. At
> least, we should change the name then. handler is too cute for a globally
> visible function.

Adding mod_export is obviously the right first step, and probably ought to
fix this particular bug.  I haven't got time to change the name `handler'
at the moment, but replacing it by zhandler sounds sensible.

Index: Src/signals.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/signals.c,v
retrieving revision 1.17
diff -u -r1.17 signals.c
--- Src/signals.c	2001/05/23 08:53:12	1.17
+++ Src/signals.c	2001/06/13 09:28:31
@@ -400,7 +400,7 @@
 /* the signal handler */
  
 /**/
-RETSIGTYPE
+mod_export RETSIGTYPE
 handler(int sig)
 {
     sigset_t newmask, oldmask;

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: General unqueue_signal problem

[Bart Schaefer]

On Jun 13, 10:34am, Andrej Borsenkow wrote:
} Subject: General unqueue_signal problem
}
} > ld: 0711-317 ERROR: Undefined symbol: .handler
} 
} This comes from unqueue_signals() macro. This macro directly calls
} handler() from signals.c (at least, I presume it is this one). But
} as I understand, zftp.c sometimes install its own handler. Any other
} module may possible install own handler as well.

It would be a very bad idea in most cases for a module to install its
own signal handler.  Dispatch of the `trap' mechanism is done through
the handler() function, etc.  zftp goes to some lengths to do the right
thing in spite of this.

} I do not understand how signal queuing works - anybody cares to check
} it?

Most of the time signals that zsh doesn't want can simply be blocked and
the OS will queue them up and deliver them when they're unblocked.  In a
few cases it needs to let the signal be delivered but avoid dispatching
the traps mechanism or other code that would (for example) call malloc().

So zsh sets up its own internal queue (really, just pointers into a fixed
array of integers) where handler() records the numbers of the signals it
has caught.  When signals are dequeued, handler() is called a second time
to dispatch the signal as it would have if queuing had not been in force.

Since the signal wouldn't have gotten into the queue in the first place
unless handler() caught it, handler() is the right function to call to
finish dispatching it later, even if some other handler has been put in
place in the meantime.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: General unqueue_signal problem

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> Adding mod_export is obviously the right first step, and probably ought to
> fix this particular bug.  I haven't got time to change the name `handler'
> at the moment, but replacing it by zhandler sounds sensible.

Here's the patchlet for that.

Bye
  Sven

Index: Src/signals.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/signals.c,v
retrieving revision 1.18
diff -u -r1.18 signals.c
--- Src/signals.c	2001/06/13 11:50:09	1.18
+++ Src/signals.c	2001/06/18 07:22:52
@@ -93,7 +93,7 @@
 #ifdef POSIX_SIGNALS
     struct sigaction act;
  
-    act.sa_handler = (SIGNAL_HANDTYPE) handler;
+    act.sa_handler = (SIGNAL_HANDTYPE) zhandler;
     sigemptyset(&act.sa_mask);        /* only block sig while in handler */
     act.sa_flags = 0;
 # ifdef SA_INTERRUPT                  /* SunOS 4.x */
@@ -401,7 +401,7 @@
  
 /**/
 mod_export RETSIGTYPE
-handler(int sig)
+zhandler(int sig)
 {
     sigset_t newmask, oldmask;
 
Index: Src/signals.h
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/signals.h,v
retrieving revision 1.3
diff -u -r1.3 signals.h
--- Src/signals.h	2001/01/16 13:44:20	1.3
+++ Src/signals.h	2001/06/18 07:22:52
@@ -82,7 +82,7 @@
 	sigset_t oset; \
 	queue_front = (queue_front + 1) % MAX_QUEUE_SIZE; \
 	oset = signal_setmask(signal_mask_queue[queue_front]); \
-	handler(signal_queue[queue_front]);  /* handle queued signal   */ \
+	zhandler(signal_queue[queue_front]);  /* handle queued signal   */ \
 	signal_setmask(oset); \
     } \
 } while (0)

-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: General unqueue_signal problem

[Peter Stephenson]

Sven Wischnowsky wrote:
> Peter Stephenson wrote:
> > Adding mod_export is obviously the right first step, and probably ought to
> > fix this particular bug.  I haven't got time to change the name `handler'
> > at the moment, but replacing it by zhandler sounds sensible.
> 
> Here's the patchlet for that.

I'd feel happier if handler were changed to zhandler for systems that don't
use POSIX signals, too.

Of course, *I* would never commit a patch without a thorough review of all
effects.  Ummm....

Index: Src/signals.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/signals.c,v
retrieving revision 1.19
diff -u -r1.19 signals.c
--- Src/signals.c	2001/06/18 07:24:23	1.19
+++ Src/signals.c	2001/06/18 09:17:49
@@ -105,7 +105,7 @@
 # ifdef BSD_SIGNALS
     struct sigvec vec;
  
-    vec.sv_handler = (SIGNAL_HANDTYPE) handler;
+    vec.sv_handler = (SIGNAL_HANDTYPE) zhandler;
     vec.sv_mask = sigmask(sig);    /* mask out this signal while in handler    */
 #  ifdef SV_INTERRUPT
     vec.sv_flags = SV_INTERRUPT;   /* make sure system calls are not restarted */
@@ -115,9 +115,9 @@
 #  ifdef SYSV_SIGNALS
     /* we want sigset rather than signal because it will   *
      * block sig while in handler.  signal usually doesn't */
-    sigset(sig, handler);
+    sigset(sig, zhandler);
 #  else  /* NO_SIGNAL_BLOCKING (bummer) */
-    signal(sig, handler);
+    signal(sig, zhandler);
 
 #  endif /* SYSV_SIGNALS  */
 # endif  /* BSD_SIGNALS   */


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************