[Top][All Lists]
[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.