HP-UX 11.X build/runtime issues for emacs 22.2

[Richard Lloyd]

I thought I'd report on the various issues I have had building and running
emacs 22.2 on HP-UX 11.X (11.11/11.23/11.31 on both PA-RISC and Itanium
platforms). I'm using the latest HP's ANSI C compiler with all the latest
patches applied to it and am building the Motif interface
(--with-x-toolkit=motif).

Here's the HP-UX 11.X issues:

* src/vm-limit.c has #ifdef HAVE_GETRLIMIT...#else...#endif sections
  (i.e. line 36 onwards and line 158 onwards) and yet the configure script
  never tests for getrlimit() and hence config.h never has any HAVE_GETRLIMIT
  definition. Yes, configure does test for setrlimit() and sets HAVE_SETRLIMIT
  though!

* Following on from the above point, the #else code in src/vm-limit.c
  between lines 173 and 188 - only run if HAVE_GETRLIMIT isn't defined (which
  it never is, as I said) - can cause a crash at line 182 on some HP-UX
  machines:
  cp = (char *) (*real_morecore) (0);

  However, if I compile with -DHAVE_GETRLIMIT, which forces the code to
  use the getrlimit() calls (HP-UX 11.X has getrlimit()), the code doesn't
  crash.

* Sadly, similar code to the assignment above is present in src/alloc.c,
  namely at line 278:

  POINTER new = (*real_morecore)(0);

  This again can cause an HP-UX core dump, but this time there is no
  getrlimit() alternative code - maybe there should be to fix this issue
  (I wonder if HP-UX isn't the only platform with this problem)?

* src/getloadavg.c declares an "nl" struct nlist array at line 493.
  Unfortunately, this clashes directly with ncurses 5.6's "nl" variable in
  ncurses.h [line 686: extern NCURSES_EXPORT(int) nl (void); ]
  Since emacs uses ncurses, this actually makes it impossible to build
  emacs with the current ncurses release on non-VMS/SGI/Linux platforms.
  I changed all references to "nl" in src/getloadavg.c to "nl2" and this
  fixed the problem - you might to consider a similar rename for that variable.

* src/tparam.c declares a tparam() function at line 95 onwards. This is
  a function also declared by the termcap 1.3.1's termcap.h file
  (line 33), so I would suggest renaming all occurrences of tparam() in
  src/term.c, src/terminfo.c and src/tparam.c to emacs_tparam() instead.

* src/term.c has uninitialised static char * variables at lines 2179 to 2181.
  If you look at the tty_default_color_capabilities() function directly
  below, you'll see statements that read those vars (lines 2192, 2196 and
  2201), potentially without assigning to them first. I suggest that
  (char *)NULL is assigned to them when they are declared:

  static char *default_orig_pair=(char *)NULL;
  static char *default_set_foreground=(char *)NULL;
  static char *default_set_background=(char *)NULL;

* I'm sure all the developers know that the emacs binary cannot be stripped,
  but I feel this should be made very clear in the documentation since it's
  almost the only package I know of that will crash and burn if the binary
  is stripped. It's such an important point, I think it should go into the
  INSTALL document.

HP-UX Archive Librarian,    E-mail queries: hpux@connect.org.uk
Connect Internet Solutions, Official HP-UX Archive WWW sites:
Liverpool,                  United Kingdom: http://hpux.connect.org.uk/
United Kingdom.             Netherlands:    http://hpux.its.tudelft.nl/
                            Canada:         http://hpux.ece.ualberta.ca/
                            United States:  http://hpux.cs.utah.edu/



-- 
This e-mail (and any attachments) is private and confidential. If you have 
received it in error, please notify the sender immediately and delete it 
from your system. Do not use, copy or disclose the information in any way 
nor act in reliance on it.

Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of Connect
Internet Solutions Ltd. This e-mail and any attachments are believed to be
virus free but it is the recipient's responsibility to ensure that they are.

Connect Internet Solutions Ltd
(A company registered in England No: 04424350)
Registered Office: Faraday House, Liverpool Digital, Edge Lane,
Liverpool, L7 9NJ
Telephone: +44 (0) 151 282 4321
Fax: +44 (0) 151 282 4322
VAT registration number: 758 2838 85