bug#6811: [PATCH] emacs-23.2 on hpux

bug#6811: [PATCH] emacs-23.2 on hpux

[Peter O'Gorman]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Hi,

Attached is a patch that allows us to build emacs-23.2 on our HP-UX
systems (10.20, 11.00 and 11.11 PA-RISC and 11.23, 11.31 both PA and
IA64).

Older hpux systems do not have setegid(), so I instead #defined it using
setregid. I must admit to being a little worried about this, simply
because the setegid() usage was introduced to fix a security flaw.

ORDINARY_LINK works. All of our hpux systems have termios.

We had problems both on HPUX and AIX crashing running temacs during the
build with a memory fault, turns out to be due to the fact that
DATA_SEG_BITS was not being added back in. This may not be the best fix
for the problem, but works for us.

Other notes:
Please restore the OSF/1 files etc. we still build on an OSF/1 system.
We also build on solaris 6, please don't remove it.

Peter
-- 
Peter O'Gorman
pogma@thewrittenword.com

[-- Attachment #2: emacs_23_2_hpux.patch --]
[-- Type: text/plain, Size: 3080 bytes --]

Index: configure.in
===================================================================
--- configure.in.orig	2010-08-02 22:49:24.298009472 +0000
+++ configure.in	2010-08-06 16:01:20.204304769 +0000
@@ -504,6 +504,10 @@
     CFLAGS="-D_INCLUDE__STDC_A1_SOURCE $CFLAGS"
   ;;
 
+  ia64*-hp-hpux1[1-9]* )
+    machine=hp800 opsys=hpux11
+  ;;
+
   hppa*-*-linux-gnu* )
     machine=hp800 opsys=gnu-linux
   ;;
@@ -2333,7 +2337,7 @@
 sendto recvfrom getsockopt setsockopt getsockname getpeername \
 gai_strerror mkstemp getline getdelim mremap memmove fsync sync bzero \
 memset memcmp difftime memcpy mempcpy mblen mbrlen posix_memalign \
-cfmakeraw cfsetspeed)
+setregid setegid cfmakeraw cfsetspeed)
 
 AC_CHECK_HEADERS(sys/un.h)
 
Index: src/s/hpux10-20.h
===================================================================
--- src/s/hpux10-20.h.orig	2010-08-02 22:49:24.309919775 +0000
+++ src/s/hpux10-20.h	2010-08-06 15:37:50.432830578 +0000
@@ -31,6 +31,8 @@
 
 #define HPUX
 
+#define ORDINARY_LINK
+
 /* SYSTEM_TYPE should indicate the kind of system you are using.
  It sets the Lisp variable system-type.  */
 
@@ -46,7 +48,8 @@
  *	for terminal control.
  */
 
-#define HAVE_TERMIO
+#define NO_TERMIO
+#define HAVE_TERMIOS
 
 /*
  *	Define HAVE_PTYS if the system supports pty devices.
@@ -116,7 +119,9 @@
 #define NO_EDITRES
 
 /* Tested in getloadavg.c.  */
+#ifndef HAVE_PSTAT_GETDYNAMIC
 #define HAVE_PSTAT_GETDYNAMIC
+#endif
 
 /* Eric Backus <ericb@lsid.hp.com> says, HP-UX 9.x on HP 700 machines
    has a broken `rint' in some library versions including math library
Index: src/s/hpux11.h
===================================================================
--- src/s/hpux11.h.orig	2010-08-02 22:49:24.302598951 +0000
+++ src/s/hpux11.h	2010-08-03 04:21:16.274466073 +0000
@@ -12,5 +12,9 @@
    then close and reopen it in the child.  */
 #define USG_SUBTTY_WORKS
 
+#if __ia64
+#define CANNOT_DUMP 1
+#endif
+
 /* arch-tag: f5a3d780-82cd-4a9a-832e-a4031aab788b
    (do not change this comment) */
Index: lib-src/movemail.c
===================================================================
--- lib-src/movemail.c.orig	2010-08-06 15:44:45.000000000 +0000
+++ lib-src/movemail.c	2010-08-06 15:46:51.732281428 +0000
@@ -151,6 +151,14 @@
 extern char *rindex __P((const char *, int));
 #endif
 
+#ifndef HAVE_SETEGID
+# ifdef HAVE_SETREGID
+#  define setegid(x) setregid(-1,x)
+# else
+#  error This system has neither setegid nor setregid
+# endif
+#endif
+
 void fatal ();
 void error ();
 void pfatal_with_name ();
Index: src/lisp.h
===================================================================
--- src/lisp.h.orig	2010-08-06 15:41:41.000000000 +0000
+++ src/lisp.h	2010-08-06 15:41:54.344492292 +0000
@@ -431,9 +431,12 @@
 
 #define XSET(var, type, ptr) \
    ((var) = ((EMACS_INT)(type) << VALBITS) + ((EMACS_INT) (ptr) & VALMASK))
+#ifdef DATA_SEG_BITS
 
+#define XPNTR(a) ((EMACS_UINT) (((a) & VALMASK) | DATA_SEG_BITS))
+#else
 #define XPNTR(a) ((EMACS_UINT) ((a) & VALMASK))
-
+#endif
 #endif /* not USE_LSB_TAG */
 
 #else /* USE_LISP_UNION_TYPE */

bug#6811: [PATCH] emacs-23.2 on hpux

[Dan Nicolaescu]

"Peter O'Gorman" <pogma@thewrittenword.com> writes:

> Hi,
>
> Attached is a patch that allows us to build emacs-23.2 on our HP-UX
> systems (10.20, 11.00 and 11.11 PA-RISC and 11.23, 11.31 both PA and
> IA64).

Thanks!

> Index: configure.in
> ===================================================================
> --- configure.in.orig	2010-08-02 22:49:24.298009472 +0000
> +++ configure.in	2010-08-06 16:01:20.204304769 +0000
> @@ -504,6 +504,10 @@
>      CFLAGS="-D_INCLUDE__STDC_A1_SOURCE $CFLAGS"
>    ;;
>  
> +  ia64*-hp-hpux1[1-9]* )
> +    machine=hp800 opsys=hpux11

I think new ports need to be approved by the maintainers. 
This looks a bit odd.
Shouldn't the machine file be ia64?  Or a new file with ia64 in the name?


> Index: src/s/hpux10-20.h
> ===================================================================
> --- src/s/hpux10-20.h.orig	2010-08-02 22:49:24.309919775 +0000
> +++ src/s/hpux10-20.h	2010-08-06 15:37:50.432830578 +0000
> @@ -31,6 +31,8 @@
>  
>  #define HPUX
>  
> +#define ORDINARY_LINK
> +
>  /* SYSTEM_TYPE should indicate the kind of system you are using.
>   It sets the Lisp variable system-type.  */
>  
> @@ -46,7 +48,8 @@
>   *	for terminal control.
>   */
>  
> -#define HAVE_TERMIO
> +#define NO_TERMIO
> +#define HAVE_TERMIOS

I'll check these in.  The last hunk is especially interesting, as hpux
was the last platform to use HAVE_TERMIO, so that will allow for a lot
of simplifications in the code...



>  /* Tested in getloadavg.c.  */
> +#ifndef HAVE_PSTAT_GETDYNAMIC
>  #define HAVE_PSTAT_GETDYNAMIC
> +#endif

If autoconf sets HAVE_PSTAT_GETDYNAMIC, then it seems that it's better
to just remove the #define.


>  
>  /* Eric Backus <ericb@lsid.hp.com> says, HP-UX 9.x on HP 700 machines
>     has a broken `rint' in some library versions including math library
> Index: src/s/hpux11.h
> ===================================================================
> --- src/s/hpux11.h.orig	2010-08-02 22:49:24.302598951 +0000
> +++ src/s/hpux11.h	2010-08-03 04:21:16.274466073 +0000
> @@ -12,5 +12,9 @@
>     then close and reopen it in the child.  */
>  #define USG_SUBTTY_WORKS
>  
> +#if __ia64
> +#define CANNOT_DUMP 1
> +#endif

This looks bad, we don't have any port in the tree that does CANNOT_DUMP.
Does it work if you dump using unexelf.o?

> Index: src/lisp.h
> ===================================================================
> --- src/lisp.h.orig	2010-08-06 15:41:41.000000000 +0000
> +++ src/lisp.h	2010-08-06 15:41:54.344492292 +0000
> @@ -431,9 +431,12 @@
>  
>  #define XSET(var, type, ptr) \
>     ((var) = ((EMACS_INT)(type) << VALBITS) + ((EMACS_INT) (ptr) & VALMASK))
> +#ifdef DATA_SEG_BITS
>  
> +#define XPNTR(a) ((EMACS_UINT) (((a) & VALMASK) | DATA_SEG_BITS))
> +#else
>  #define XPNTR(a) ((EMACS_UINT) ((a) & VALMASK))
> -
> +#endif
>  #endif /* not USE_LSB_TAG */
>  
>  #else /* USE_LISP_UNION_TYPE */

There's some code that does DATA_SEG_BITS further down in the file,
maybe some untangling is needed in lisp.h...

bug#6811: [PATCH] emacs-23.2 on hpux

[Jan Djärv]

Dan Nicolaescu skrev 2010-08-09 11.47:
> "Peter O'Gorman"<pogma@thewrittenword.com>  writes:
>>
>> -#define HAVE_TERMIO
>> +#define NO_TERMIO
>> +#define HAVE_TERMIOS
>
> I'll check these in.  The last hunk is especially interesting, as hpux
> was the last platform to use HAVE_TERMIO, so that will allow for a lot
> of simplifications in the code...
>

This must have been a leftover from a very old HP-UX.  AFAIK, HP-UX has had 
termios since HP-UX 7 or 8.

	Jan D.

bug#6811: [PATCH] emacs-23.2 on hpux

[Dan Nicolaescu]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Dan Nicolaescu skrev 2010-08-09 11.47:
>> "Peter O'Gorman"<pogma@thewrittenword.com>  writes:
>>>
>>> -#define HAVE_TERMIO
>>> +#define NO_TERMIO
>>> +#define HAVE_TERMIOS
>>
>> I'll check these in.  The last hunk is especially interesting, as hpux
>> was the last platform to use HAVE_TERMIO, so that will allow for a lot
>> of simplifications in the code...
>>
>
> This must have been a leftover from a very old HP-UX.  AFAIK, HP-UX
> has had termios since HP-UX 7 or 8.

Unfortunately we don't really have platform maintainers, so things
like this do not get updated...

bug#6811: [PATCH] emacs-23.2 on hpux

[Dan Nicolaescu]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Dan Nicolaescu skrev 2010-08-09 11.47:
>> "Peter O'Gorman"<pogma@thewrittenword.com>  writes:
>>>
>>> -#define HAVE_TERMIO
>>> +#define NO_TERMIO
>>> +#define HAVE_TERMIOS
>>
>> I'll check these in.  The last hunk is especially interesting, as hpux
>> was the last platform to use HAVE_TERMIO, so that will allow for a lot
>> of simplifications in the code...
>>
>
> This must have been a leftover from a very old HP-UX.  AFAIK, HP-UX
> has had termios since HP-UX 7 or 8.

How about this code from systty.h:


/* EMACS_HAVE_TTY_PGRP is true if we can get and set the tty's current
   controlling process group.

   EMACS_GET_TTY_PGRP(int FD, int *PGID) sets *PGID the terminal FD's
   current process group.  Return -1 if there is an error.

   EMACS_SET_TTY_PGRP(int FD, int *PGID) sets the terminal FD's
   current process group to *PGID.  Return -1 if there is an error.  */

/* HPUX tty process group stuff doesn't work, says the anonymous voice
   from the past.  */
#ifndef HPUX
#ifdef TIOCGPGRP
#define EMACS_HAVE_TTY_PGRP
#else
#ifdef HAVE_TERMIOS
#define EMACS_HAVE_TTY_PGRP
#endif /* HAVE_TERMIOS */
#endif /* TIOCGPGRP */
#endif /* not HPUX */

can the HPUX special case be removed now? 

bug#6811: [PATCH] emacs-23.2 on hpux

[Jan Djärv]

Dan Nicolaescu skrev 2010-08-09 22.42:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> This must have been a leftover from a very old HP-UX.  AFAIK, HP-UX
>> has had termios since HP-UX 7 or 8.
>
> How about this code from systty.h:
>
>
> /* EMACS_HAVE_TTY_PGRP is true if we can get and set the tty's current
>     controlling process group.
>
>     EMACS_GET_TTY_PGRP(int FD, int *PGID) sets *PGID the terminal FD's
>     current process group.  Return -1 if there is an error.
>
>     EMACS_SET_TTY_PGRP(int FD, int *PGID) sets the terminal FD's
>     current process group to *PGID.  Return -1 if there is an error.  */
>
> /* HPUX tty process group stuff doesn't work, says the anonymous voice
>     from the past.  */
> #ifndef HPUX
> #ifdef TIOCGPGRP
> #define EMACS_HAVE_TTY_PGRP
> #else
> #ifdef HAVE_TERMIOS
> #define EMACS_HAVE_TTY_PGRP
> #endif /* HAVE_TERMIOS */
> #endif /* TIOCGPGRP */
> #endif /* not HPUX */
>
> can the HPUX special case be removed now?

I don't have access to any HP-UX so I can't check.  But I do remmeber using 
tcsetpgrp/tcgetpgrp on HP-UX in the early nineties.  HP-UX was big on POSIX.1 
back then and those functions are from there.  They are in the online HP-UX 
man pages, from 2005.

	Jan D.

bug#6811: [PATCH] emacs-23.2 on hpux

[Andreas Schwab]

Dan Nicolaescu <dann@gnu.org> writes:

> "Peter O'Gorman" <pogma@thewrittenword.com> writes:
>
>> Index: configure.in
>> ===================================================================
>> --- configure.in.orig	2010-08-02 22:49:24.298009472 +0000
>> +++ configure.in	2010-08-06 16:01:20.204304769 +0000
>> @@ -504,6 +504,10 @@
>>      CFLAGS="-D_INCLUDE__STDC_A1_SOURCE $CFLAGS"
>>    ;;
>>  
>> +  ia64*-hp-hpux1[1-9]* )
>> +    machine=hp800 opsys=hpux11
>
> I think new ports need to be approved by the maintainers. 
> This looks a bit odd.
> Shouldn't the machine file be ia64?  Or a new file with ia64 in the name?

Now that WORDS_BIG_ENDIAN is no longer hardcoded there is no reason any
more not to use machine=ia64.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#6811: [PATCH] emacs-23.2 on hpux

[Peter O'Gorman]

On Mon, Aug 09, 2010 at 05:47:58AM -0400, Dan Nicolaescu wrote:
> > +  ia64*-hp-hpux1[1-9]* )
> > +    machine=hp800 opsys=hpux11
> 
> I think new ports need to be approved by the maintainers. 
> This looks a bit odd.
> Shouldn't the machine file be ia64?  Or a new file with ia64 in the name?

At least for 23.2 ia64.h doesn't work. We'll try again on the next
release.

> 
> >  /* Tested in getloadavg.c.  */
> > +#ifndef HAVE_PSTAT_GETDYNAMIC
> >  #define HAVE_PSTAT_GETDYNAMIC
> > +#endif
> 
> If autoconf sets HAVE_PSTAT_GETDYNAMIC, then it seems that it's better
> to just remove the #define.

Sure, autoconf does set it.

> >  
> > +#if __ia64
> > +#define CANNOT_DUMP 1
> > +#endif
> 
> This looks bad, we don't have any port in the tree that does CANNOT_DUMP.
> Does it work if you dump using unexelf.o?

No.

> >  
> >  #else /* USE_LISP_UNION_TYPE */
> 
> There's some code that does DATA_SEG_BITS further down in the file,
> maybe some untangling is needed in lisp.h...

That would be nice, it gave me a headache :-)

Peter
-- 
Peter O'Gorman
pogma@thewrittenword.com

bug#6811: [PATCH] emacs-23.2 on hpux

[Dan Nicolaescu]

"Peter O'Gorman" <pogma@thewrittenword.com> writes:

> On Mon, Aug 09, 2010 at 05:47:58AM -0400, Dan Nicolaescu wrote:
>> > +  ia64*-hp-hpux1[1-9]* )
>> > +    machine=hp800 opsys=hpux11
>> 
>> I think new ports need to be approved by the maintainers. 
>> This looks a bit odd.
>> Shouldn't the machine file be ia64?  Or a new file with ia64 in the name?
>
> At least for 23.2 ia64.h doesn't work. We'll try again on the next
> release.

Could you try it before the next release, that's the only way it would
have a chance to be fixed, there's not that many users of HPUX on the
emacs mailing lists.

>> >  /* Tested in getloadavg.c.  */
>> > +#ifndef HAVE_PSTAT_GETDYNAMIC
>> >  #define HAVE_PSTAT_GETDYNAMIC
>> > +#endif
>> 
>> If autoconf sets HAVE_PSTAT_GETDYNAMIC, then it seems that it's better
>> to just remove the #define.
>
> Sure, autoconf does set it.

OK, I'll remove it then.

>> > +#if __ia64
>> > +#define CANNOT_DUMP 1
>> > +#endif
>> 
>> This looks bad, we don't have any port in the tree that does CANNOT_DUMP.
>> Does it work if you dump using unexelf.o?
>
> No.

Bummer, then, IMVHO, this is not ready to be included...

bug#6811: [PATCH] emacs-23.2 on hpux

[Stefan Monnier]

>>> > +  ia64*-hp-hpux1[1-9]* )
>>> > +    machine=hp800 opsys=hpux11
>>> I think new ports need to be approved by the maintainers.

That's OK.

>>> This looks a bit odd.  Shouldn't the machine file be ia64?  Or a new
>>> file with ia64 in the name?

hp800.h is the only hp*.h we have, so it seems to apply to all hp machines.
I don't think we need to worry too much about the presence/absence of
ia64 in the name: most of the stuff in hp800.h (the one from emacs-23,
I mean) is OS-dependent rather than machine dependent, as is almost
always the case nowadays.

>>> > +#if __ia64
>>> > +#define CANNOT_DUMP 1
>>> > +#endif
>>> This looks bad, we don't have any port in the tree that does CANNOT_DUMP.
>>> Does it work if you dump using unexelf.o?
>> No.
> Bummer, then, IMVHO, this is not ready to be included...

It's not ready for real use, but that doesn't mean we can't include it.


        Stefan

bug#6811: [PATCH] emacs-23.2 on hpux

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> hp800.h is the only hp*.h we have, so it seems to apply to all hp machines.
> I don't think we need to worry too much about the presence/absence of
> ia64 in the name:

That does not make sense, hp800 are hppa-based systems.  A lot of HPUX
configurations were removed 2 years ago, including support for
m68k-based systems (hp9000s300).

> most of the stuff in hp800.h (the one from emacs-23,
> I mean) is OS-dependent rather than machine dependent, as is almost
> always the case nowadays.

Then this stuff should be moved to s/*.h.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#6811: [PATCH] emacs-23.2 on hpux

[Stefan Monnier]

>> most of the stuff in hp800.h (the one from emacs-23,
>> I mean) is OS-dependent rather than machine dependent, as is almost
>> always the case nowadays.

> Then this stuff should be moved to s/*.h.

Probably, tho it'd be more better to move them to autoconf.
In trunk, hp800 only defines EXPLICIT_SIGN_EXTEND, which should not be
hard to autoconfigure.


        Stefan

bug#6811: [PATCH] emacs-23.2 on hpux

[Chong Yidong]

> Attached is a patch that allows us to build emacs-23.2 on our HP-UX
> systems (10.20, 11.00 and 11.11 PA-RISC and 11.23, 11.31 both PA and
> IA64).

I think all the pieces of this patch are in the branch now.

Hopefully, someone can work on the inability to dump on ia-64.

bug#6811: emacs-23.2 on hpux

[Andy Moreton]

On Sun 23 Jan 2011, Chong Yidong wrote:

>> Attached is a patch that allows us to build emacs-23.2 on our HP-UX
>> systems (10.20, 11.00 and 11.11 PA-RISC and 11.23, 11.31 both PA and
>> IA64).
>
> I think all the pieces of this patch are in the branch now.
>
> Hopefully, someone can work on the inability to dump on ia-64.

The change in revno: 100409 for this bug doesn't build on Win32 with
mingw gcc:

gcc -o oo-spd/i386/movemail.exe  -gdwarf-2 -g3  -mno-cygwin
 oo-spd/i386/movemail.o oo-spd/i386/pop.o oo-spd/i386/ntlib.o
 oo-spd/i386/getopt.o oo-spd/i386/getopt1.o -lwsock32   -ladvapi32
oo-spd/i386/movemail.o: In function `main':
C:\emacs\bzr\emacs-23\lib-src/movemail.c:363: undefined reference to `setregid'
C:\emacs\bzr\emacs-23\lib-src/movemail.c:390: undefined reference to `setregid'
C:\emacs\bzr\emacs-23\lib-src/movemail.c:487: undefined reference to `setregid'
C:\emacs\bzr\emacs-23\lib-src/movemail.c:522: undefined reference to `setregid'
collect2: ld returned 1 exit status
mingw32-make[2]: *** [oo-spd/i386/movemail.exe] Error 1
mingw32-make[2]: Leaving directory `C:/emacs/bzr/emacs-23/lib-src'
mingw32-make[1]: *** [all-other-dirs-gmake] Error 2
mingw32-make[1]: Leaving directory `C:/emacs/bzr/emacs-23/nt'
mingw32-make: *** [bootstrap] Error 2

bug#6811: emacs-23.2 on hpux

[Chong Yidong]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> The change in revno: 100409 for this bug doesn't build on Win32 with
> mingw gcc:

Should be fixed now, thanks for the heads-up.

bug#6811: emacs-23.2 on hpux

[Glenn Morris]

Version: 27.1

Emacs now has a portable dumper, which should help things like this.
This report is 9 years old. If there is still any interest in Emacs on
HP-UX, and there are problems with the new dumping approach, it's better
to open a new report.