emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs can't be built on HPUX 10.


From: Kenichi Handa
Subject: Re: Emacs can't be built on HPUX 10.
Date: Sat, 11 Nov 2000 09:43:54 +0900 (JST)

Kenichi Handa <address@hidden> writes:
> Emacs can't be compiled on this system.
> % uname -a
> HP-UX hpux B.10.20 A 9000/785 2002836476 two-user license

I found that Emacs 21 can be compiled by HPUX native C
compiler with the following three patches.

(1) HP-UX 10.20 now has X11R6.  As this change is harmless,
I've already installed it.

        * s/hpux10.h (C_SWITCH_X_SYSTEM): Include -I/usr/include/X11R6 and
        -I/usr/contrib/X11R6/include.
        (LD_SWITCH_X_DEFAULT): Include -L/usr/lib/X11R6.

*** hpux10.h.~1.8.~     Mon Aug 14 09:35:13 2000
--- hpux10.h    Fri Nov 10 20:07:51 2000
***************
*** 43,47 ****
  #undef LD_SWITCH_X_DEFAULT
  /* However, HPUX 10 puts Xaw and Xmu in a strange place
     (if you install them at all).  So search that place.  */
! #define C_SWITCH_X_SYSTEM -I/usr/include/X11R5 -I/usr/include/Motif1.2 
-I/usr/contrib/X11R5/include
! #define LD_SWITCH_X_DEFAULT -L/usr/lib/X11R5 -L/usr/lib/Motif1.2 
-L/usr/contrib/X11R5/lib
--- 43,47 ----
  #undef LD_SWITCH_X_DEFAULT
  /* However, HPUX 10 puts Xaw and Xmu in a strange place
     (if you install them at all).  So search that place.  */
! #define C_SWITCH_X_SYSTEM  -I/usr/include/X11R6 -I/usr/include/X11R5 
-I/usr/include/Motif1.2 -I/usr/contrib/X11R6/include 
-I/usr/contrib/X11R5/include
! #define LD_SWITCH_X_DEFAULT -L/usr/lib/X11R6 -L/usr/lib/X11R5 
-L/usr/lib/Motif1.2 -L/usr/contrib/X11R5/lib

(2) On HP-UX with native C compiler, local static variable
is not kept zero cleared.  When clear_glyph_row is called at
the first time, null_row is surely zero cleared.  But, when
it is called next time, null_row is not zero cleared.  It
seems that this workaround is not harmless.  Shall I install
it?

*** dispnew.c.~1.241.~  Wed Nov  1 09:31:13 2000
--- dispnew.c   Fri Nov 10 21:22:11 2000
***************
*** 976,987 ****
     changes in the glyph_row structure, i.e. addition or removal of
     structure members.  */
  
  void
  clear_glyph_row (row)
       struct glyph_row *row;
  {
    struct glyph *p[1 + LAST_AREA];
-   static struct glyph_row null_row;
  
    /* Save pointers.  */
    p[LEFT_MARGIN_AREA] = row->glyphs[LEFT_MARGIN_AREA];
--- 976,988 ----
     changes in the glyph_row structure, i.e. addition or removal of
     structure members.  */
  
+ static struct glyph_row null_row;
+ 
  void
  clear_glyph_row (row)
       struct glyph_row *row;
  {
    struct glyph *p[1 + LAST_AREA];
  
    /* Save pointers.  */
    p[LEFT_MARGIN_AREA] = row->glyphs[LEFT_MARGIN_AREA];


(3) For sysdep.c, we need two fixes.  The first one is
simple, just move the code of extern declaration for h_error
after <netdb.h> is included.  This is because TRY_AGAIN is
defined IN <netdb.h>.  The second one is the problem of
`ospeed'.  It seems that HPUX 10.20 doesn't have the
variable `ospeed'.  So, "extern XXX opseed" hack doesn't
work.  We have discussed on `ospeed' problem long ago and my
conclusion was to use Emacs's internal variable only (see
the attached mail at the tail).

Shall I install this chang?

*** sysdep.c.~1.211.~   Wed Nov  8 21:17:16 2000
--- sysdep.c    Fri Nov 10 21:29:05 2000
***************
*** 60,71 ****
  #undef fwrite
  #endif
  
- #ifdef TRY_AGAIN
- #ifndef HAVE_H_ERRNO
- extern int h_errno;
- #endif
- #endif /* TRY_AGAIN */
- 
  #include <stdio.h>
  #include <sys/types.h>
  #include <sys/stat.h>
--- 60,65 ----
***************
*** 234,251 ****
  
  #ifdef HAVE_SPEED_T
  #include <termios.h>
! extern speed_t ospeed;
  #else
  #if defined (HAVE_LIBNCURSES) && ! defined (NCURSES_OSPEED_T)
! extern short ospeed;
  #else
  #if defined (HAVE_TERMIOS_H) && defined (LINUX)
  #include <termios.h>
  /* HJL's version of libc is said to need this on the Alpha.
     On the other hand, DEC OSF1 on the Alpha needs ospeed to be a short.  */
! extern speed_t ospeed;
  #else
! extern short ospeed;
  #endif
  #endif
  #endif
--- 228,245 ----
  
  #ifdef HAVE_SPEED_T
  #include <termios.h>
! speed_t ospeed;
  #else
  #if defined (HAVE_LIBNCURSES) && ! defined (NCURSES_OSPEED_T)
! short ospeed;
  #else
  #if defined (HAVE_TERMIOS_H) && defined (LINUX)
  #include <termios.h>
  /* HJL's version of libc is said to need this on the Alpha.
     On the other hand, DEC OSF1 on the Alpha needs ospeed to be a short.  */
! speed_t ospeed;
  #else
! short ospeed;
  #endif
  #endif
  #endif
***************
*** 2286,2291 ****
--- 2280,2291 ----
  #endif /* HAVE_SOCKETS */
  #endif /* not VMS */
  #endif /* not BSD4_1 */
+ 
+ #ifdef TRY_AGAIN
+ #ifndef HAVE_H_ERRNO
+ extern int h_errno;
+ #endif
+ #endif /* TRY_AGAIN */
  
  void
  init_system_name ()


---
Ken'ichi HANDA
address@hidden

---old mail---------------------------------------------------------
Date: Tue, 27 Jun 2000 13:01:49 +0200 (CEST)
X-Authentication-Warning: gerd.segv.de: gerd set sender to address@hidden using 
-f
Sender: address@hidden
To: Kenichi Handa <address@hidden>
Cc: address@hidden
Subject: Re: warning by `ld' while compiling Emacs
Reply-To: address@hidden
From: Gerd Moellmann <address@hidden>
In-Reply-To: Kenichi Handa's message of "Tue, 20 Jun 2000 08:21:47 +0900 (JST)"
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/21.0.90
Content-Type: text/plain; charset=us-ascii
Content-Length: 2283

Kenichi Handa <address@hidden> writes:

> > AFAIK, Emacs need to read the value ospeed to determine the baud rate
> > of the terminal on which it is running.  So, renaming the variable
> > doesn't help.  I think we must find out why Emacs is using a different
> > size for ospeed and fix that, instead.
> 
> On Solaris, we get these lines in src/config.h.
> 
> #define HAVE_TERMIOS_H 1
> #define HAVE_SPEED_T 1                /* speed_t typedef in termios.h */
> 
> Thus src/terminfo.c declares ospeed as speed_t.  And the
> type speed_t is declared as `unsigned int' in
> sys/termios.h.
> 
> But, it seems that Solaris's termcap.o in
> /usr/ccs/bin/libcurses.a contains the extern variable
> `ospeed' and that is declared as two-byte (perhaps `short').
> 
> % nm /usr/ccs/lib/libcurses.a |grep ospeed
> [10]    |         0|       0|NOTY |GLOB |0    |UNDEF  |cfgetospeed
> [35]    |         0|       0|NOTY |GLOB |0    |UNDEF  |cfgetospeed
> [8]     |         0|       0|NOTY |GLOB |0    |UNDEF  |cfgetospeed
> [9]     |         0|       0|NOTY |GLOB |0    |UNDEF  |cfgetospeed
> [53]    |         0|       0|NOTY |GLOB |0    |UNDEF  |cfgetospeed
> [11]    |         2|       2|OBJT |GLOB |0    |COMMON |ospeed
>                            |  |     +--- global
>                            |  +--- array or variable
>                            +--- two-byte
> 
> I think that is the reason of the warning.
> 

Yes, probably it is.

> I don't know exactly what happens if both of two objects
> linked together (this case termcap.o of libcurses.a and
> terminfo.o of Emacs) contain the same non-static variable
> name and the third object (sysdep.o of Emacs) refers to it
> by extern declaration.
> 
> But, anyway, it seems that Emacs doesn't read the value of
> `ospeed' which is set in a library, but tries to get a
> proper value for it through various system function calls
> (in the case of Solaris, by cfgetospeed) and set `ospeed' to
> it in init_baut_rate.  Then, I think changing the variable
> name should work.  (unless it is important to set the value
> of library's `ospeed' by Emacs).

If Emacs doesn't read from the system's `ospeed', that's good news
because we could get rid of it, and use an Emacs-internal variable
instead.  Before changing this, I'd double-check this, though.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]