bug#7642: Build failure on NetBSD 5.0.2 on IA-32

bug#7642: Build failure on NetBSD 5.0.2 on IA-32

[Chong Yidong]

Nelson H. F. Beebe reports a build failure for the 23.2.91 pretest on
NetBSD 5.0.2 on IA-32.  The last Emacs version to build ok was 23.1.96
in April 2010:

> On NetBSD, the configure step with both native /usr/bin/cc and
> gcc-4.4-20090123 fails like this:
>
> ...
> checking whether `alloca.c' needs Cray hooks... no
> checking stack direction for C alloca... -1
> configure: error: a system implementation of alloca is required

bug#7642: Build failure on NetBSD 5.0.2 on IA-32

[Glenn Morris]

Chong Yidong wrote:

> Nelson H. F. Beebe reports a build failure for the 23.2.91 pretest on
> NetBSD 5.0.2 on IA-32.  The last Emacs version to build ok was 23.1.96
> in April 2010:
>
>> On NetBSD, the configure step with both native /usr/bin/cc and
>> gcc-4.4-20090123 fails like this:
>>
>> ...
>> checking whether `alloca.c' needs Cray hooks... no
>> checking stack direction for C alloca... -1
>> configure: error: a system implementation of alloca is required

The relevant part of the output is missing, but it looks like the
system does not have an implementation of alloca. Support for systems
without alloca was removed in 23.1. Does 23.1 currently build on that
system? What does the rest of configure's output look like?

bug#7642: Build failure on NetBSD 5.0.2 on IA-32

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Chong Yidong wrote:
>
>> Nelson H. F. Beebe reports a build failure for the 23.2.91 pretest on
>> NetBSD 5.0.2 on IA-32.  The last Emacs version to build ok was 23.1.96
>> in April 2010:
>>
>>> On NetBSD, the configure step with both native /usr/bin/cc and
>>> gcc-4.4-20090123 fails like this:
>>>
>>> ...
>>> checking whether `alloca.c' needs Cray hooks... no
>>> checking stack direction for C alloca... -1
>>> configure: error: a system implementation of alloca is required
>
> The relevant part of the output is missing, but it looks like the
> system does not have an implementation of alloca. Support for systems
> without alloca was removed in 23.1. Does 23.1 currently build on that
> system? What does the rest of configure's output look like?

Nelson, could you post the rest of the entire configure log?  Thanks.

Surely NetBSD on IA-32 should have an alloca implementation; this is
strange.

bug#7642: Build failure on NetBSD 5.0.2 on IA-32

[Nelson H. F. Beebe]

I tracked down the problem with the failing build of emacs-23.2.91 on
NetBSD 5.0.2 on IA-32, and now have a working installation of that new
version.

The problem that caused the configure failure report of

configure: error: a system implementation of alloca is required

was entirely unrelated.  On this system, the normal X11 libraries are
in /usr/X11R7/lib, but to keep old executables running, we had to
restore X11R6 libraries to /usr/local/lib; that resulted in a
link-time failure that had nothing to do with alloca().

In order to build emacs-23.2.91 on this system, I had to work like
this:

% set path=(/bin /usr/bin)
% env LDFLAGS='-Wl,-rpath,/usr/X11R7/lib -L/usr/X11R7/lib' ./configure
% make
...
ld: cannot find -lXaw3d
% ls /usr/X11*/lib/libXaw*
/usr/X11R7/lib/libXaw.a                 /usr/X11R7/lib/libXaw7.so.7.0
/usr/X11R7/lib/libXaw.so                /usr/X11R7/lib/libXaw7_p.a
/usr/X11R7/lib/libXaw.so.6              /usr/X11R7/lib/libXaw7_pic.a
/usr/X11R7/lib/libXaw.so.7              /usr/X11R7/lib/libXaw8.a
/usr/X11R7/lib/libXaw.so.8              /usr/X11R7/lib/libXaw8.so
/usr/X11R7/lib/libXaw6.so.6             /usr/X11R7/lib/libXaw8.so.8
/usr/X11R7/lib/libXaw6.so.6.1           /usr/X11R7/lib/libXaw8.so.8.0
/usr/X11R7/lib/libXaw7.a                /usr/X11R7/lib/libXaw8_p.a
/usr/X11R7/lib/libXaw7.so               /usr/X11R7/lib/libXaw8_pic.a
/usr/X11R7/lib/libXaw7.so.7             /usr/X11R7/lib/libXaw_p.a

That is a definite error: configure needs to check that -lXaw3d is
available.

Try again:

% make distclean
% env LDFLAGS='-Wl,-rpath,/usr/X11R7/lib -L/usr/X11R7/lib' ./configure --without-xaw3d
% make
...
ld: cannot find -lterminfo
% ls /usr/lib/libterm*
/usr/lib/libtermcap.a                   /usr/lib/libtermlib.a
/usr/lib/libtermcap.so                  /usr/lib/libtermlib.so
/usr/lib/libtermcap.so.0                /usr/lib/libtermlib.so.0
/usr/lib/libtermcap.so.0.6              /usr/lib/libtermlib.so.0.6
/usr/lib/libtermcap_p.a                 /usr/lib/libtermlib_p.a
/usr/lib/libtermcap_pic.a               /usr/lib/libtermlib_pic.a

That is another error: -lterminfo is hard-coded into src/Makefile.

Changing -lterminfo to -ltermlib does not help:

% make
/local/build/bare/emacs-23.2.91/src/terminfo.c:46: undefined reference to `tparm'

I then changed -ltermlib to /usr/local/lib/libncurses.a, removed all -L/usr/local/lib/
and -Wl,-rpath,/usr/local/lib instances in src/Makefile, and expanded the graphics
library options like -ljpeg to /usr/local/lib/libjpeg.a, etc.

% diff src/Makefile.org src/Makefile
41c41
< CPPFLAGS=-I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib -L/usr/local/lib
---
> CPPFLAGS=-I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib
77c77
< ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(MYCPPFLAGS) -I. -I${srcdir} -I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib -L/usr/local/lib -I/usr/X11R7/include ${CFLAGS_SOUND} ${RSVG_CFLAGS} ${DBUS_CFLAGS} ${GCONF_CFLAGS} ${CFLAGS} ${DEPFLAGS}
---
> ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(MYCPPFLAGS) -I. -I${srcdir} -I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib  -I/usr/X11R7/include ${CFLAGS_SOUND} ${RSVG_CFLAGS} ${DBUS_CFLAGS} ${GCONF_CFLAGS} ${CFLAGS} ${DEPFLAGS}
94c94
< LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) -ltiff -ljpeg -lpng -lz -lm -lgif -lXpm -lX11 $(XFT_LIBS)
---
> LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) /usr/local/lib/libtiff.a /usr/local/lib/libjpeg.a /usr/local/lib/libpng.a /usr/local/lib/libz.a -lm /usr/local/lib/libgif.a  -lXpm -lX11 $(XFT_LIBS)
101c101
< TEMACS_LDFLAGS = `echo -R/usr/X11R7/lib | sed -e 's/-R/-Wl,-rpath,/'` -Wl,-rpath,/usr/pkg/lib -L/usr/pkg/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib -Wl,-z,nocombreloc
---
> TEMACS_LDFLAGS = `echo -R/usr/X11R7/lib | sed -e 's/-R/-Wl,-rpath,/'` -Wl,-rpath,/usr/pkg/lib -L/usr/pkg/lib -Wl,-rpath,/usr/local/lib  -Wl,-z,nocombreloc
116c116
< LIBES = $(LOADLIBES) $(LIBS) $(LIBX) $(LIBSOUND) $(RSVG_LIBS) $(DBUS_LIBS) -lterminfo $(GETLOADAVG_LIBS) ${GCONF_LIBS} $(GNULIB_VAR) -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o $(GNULIB_VAR)
---
> LIBES = $(LOADLIBES) $(LIBS) $(LIBX) $(LIBSOUND) $(RSVG_LIBS) $(DBUS_LIBS) /usr/local/lib/libncurses.a $(GETLOADAVG_LIBS) ${GCONF_LIBS} $(GNULIB_VAR) -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o $(GNULIB_VAR)
141c141
< C_SWITCH_SYSTEM_1 = -I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib -L/usr/local/lib
---
> C_SWITCH_SYSTEM_1 = -I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib

That finally produced success, except for one ongoing nuisance: when
emacs loads a Lisp file, it always uses the compiled version in
preference to the source file.  At my site, I have 25 flavors of Unix,
many with a common emacs installation tree, and emacs versions back to
18.xx.  Unfortunately, emacs-22 and emacs-23 often fail to handle .elc
files from older versions, and newer ones cannot be read by older
emacs versions.  That resulted in dump-time failure:

Invalid read syntax: "invalid multibyte form"

It would be nice if, on encountering that error, emacs retried the
load of the .el file before complaining.  I solved the problem by
removing the /usr/local/share/emacs/site-lisp/*.elc files.


-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

bug#7642: Build failure on NetBSD 5.0.2 on IA-32

[Chong Yidong]

"Nelson H. F. Beebe" <beebe@math.utah.edu> writes:

> % make distclean
> % env LDFLAGS='-Wl,-rpath,/usr/X11R7/lib -L/usr/X11R7/lib' ./configure
> --without-xaw3d
> % make
> ...
> ld: cannot find -lterminfo
> % ls /usr/lib/libterm*
> /usr/lib/libtermcap.a                   /usr/lib/libtermlib.a
> ...
>
> That is another error: -lterminfo is hard-coded into src/Makefile.

The problem here is that in src/s/netbsd.h, we define

#ifdef HAVE_TERM_H
#define TERMINFO
#define LIBS_TERMCAP -lterminfo
#else
#define LIBS_TERMCAP -ltermcap
#endif

Judging by this report, the existence of term.h does not imply that
terminfo is available.

So, we should go back to the prescription originally given in Bug#6190.
Something like the following patch---Nelson, does it fix this problem?

=== modified file 'configure.in'
*** configure.in	2010-12-10 17:46:40 +0000
--- configure.in	2010-12-17 14:29:37 +0000
***************
*** 2372,2377 ****
--- 2372,2386 ----
  # than to expect to find it in ncurses.
  AC_CHECK_LIB(ncurses, tparm)
  
+ case "$opsys" in
+   netbsd)
+     AC_SEARCH_LIBS(tputs, [ncurses terminfo termcap]);
+     if test $ac_cv_search_tputs = -lterminfo; then
+       AC_DEFINE(TERMINFO, 1, [Define to 1 if you use terminfo instead of termcap.]);
+     fi
+     ;;
+ esac
+ 
  # Do we have res_init, for detecting changes in /etc/resolv.conf?
  
  resolv=no

=== modified file 'src/s/netbsd.h'
*** src/s/netbsd.h	2010-05-21 04:06:34 +0000
--- src/s/netbsd.h	2010-12-17 14:29:31 +0000
***************
*** 45,52 ****
  #define LIBS_DEBUG
  /* -lutil is not needed for NetBSD >0.9.  */
  /* #define LIBS_SYSTEM -lutil */
! #ifdef HAVE_TERM_H
! #define TERMINFO
  #define LIBS_TERMCAP -lterminfo
  #else
  #define LIBS_TERMCAP -ltermcap
--- 45,51 ----
  #define LIBS_DEBUG
  /* -lutil is not needed for NetBSD >0.9.  */
  /* #define LIBS_SYSTEM -lutil */
! #ifdef TERMINFO
  #define LIBS_TERMCAP -lterminfo
  #else
  #define LIBS_TERMCAP -ltermcap

=== modified file 'configure'
*** configure	2010-12-10 17:46:40 +0000
--- configure	2010-12-17 14:30:05 +0000
***************
*** 11833,11838 ****
--- 11833,11904 ----
  fi
  
  
+ case "$opsys" in
+   netbsd)
+     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing tputs" >&5
+ $as_echo_n "checking for library containing tputs... " >&6; }
+ if test "${ac_cv_search_tputs+set}" = set; then :
+   $as_echo_n "(cached) " >&6
+ else
+   ac_func_search_save_LIBS=$LIBS
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+ /* end confdefs.h.  */
+ 
+ /* Override any GCC internal prototype to avoid an error.
+    Use char because int might match the return type of a GCC
+    builtin and then its argument prototype would still apply.  */
+ #ifdef __cplusplus
+ extern "C"
+ #endif
+ char tputs ();
+ int
+ main ()
+ {
+ return tputs ();
+   ;
+   return 0;
+ }
+ _ACEOF
+ for ac_lib in '' ncurses terminfo termcap; do
+   if test -z "$ac_lib"; then
+     ac_res="none required"
+   else
+     ac_res=-l$ac_lib
+     LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
+   fi
+   if ac_fn_c_try_link "$LINENO"; then :
+   ac_cv_search_tputs=$ac_res
+ fi
+ rm -f core conftest.err conftest.$ac_objext \
+     conftest$ac_exeext
+   if test "${ac_cv_search_tputs+set}" = set; then :
+   break
+ fi
+ done
+ if test "${ac_cv_search_tputs+set}" = set; then :
+ 
+ else
+   ac_cv_search_tputs=no
+ fi
+ rm conftest.$ac_ext
+ LIBS=$ac_func_search_save_LIBS
+ fi
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_tputs" >&5
+ $as_echo "$ac_cv_search_tputs" >&6; }
+ ac_res=$ac_cv_search_tputs
+ if test "$ac_res" != no; then :
+   test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
+ 
+ fi
+ ;
+     if test $ac_cv_search_tputs = -lterminfo; then
+ 
+ $as_echo "#define TERMINFO 1" >>confdefs.h
+ ;
+     fi
+     ;;
+ esac
+ 
  # Do we have res_init, for detecting changes in /etc/resolv.conf?
  
  resolv=no

bug#7642: Build failure on NetBSD 5.0.2 on IA-32

[Glenn Morris]

"Nelson H. F. Beebe" wrote:

> That is a definite error: configure needs to check that -lXaw3d is
> available.

configure checks for Xaw3d headers, but not for the library:

    [AC_TRY_LINK([
#include <X11/Intrinsic.h>
#include <X11/Xaw3d/Simple.h>],
      [],

Presumably your system has the include file but does not have the
library?

In Emacs 22, there used to be a test for both an include and a library:

    AC_CHECK_HEADER(X11/Xaw3d/Scrollbar.h,
        [AC_CHECK_LIB(Xaw3d, XawScrollbarSetThumb, HAVE_XAW3D=yes)], ,


Looks like this went in the 2007-06-13 change to configure.in.

bug#7642: Build failure on NetBSD 5.0.2 on IA-32

[Glenn Morris]

"Nelson H. F. Beebe" wrote:

> That finally produced success, except for one ongoing nuisance: when
> emacs loads a Lisp file, it always uses the compiled version in
> preference to the source file.

See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2061

> Invalid read syntax: "invalid multibyte form"
>
> It would be nice if, on encountering that error, emacs retried the
> load of the .el file before complaining.  I solved the problem by
> removing the /usr/local/share/emacs/site-lisp/*.elc files.


Why is dumping trying to load files from /usr/local/share/emacs/site-lisp?

bug#7642: Build failure on NetBSD 5.0.2 on IA-32

[Chong Yidong]

> > That is a definite error: configure needs to check that -lXaw3d is
> > available.
>
> configure checks for Xaw3d headers, but not for the library:

I've committed a patch reinstating the check for the Xaw3d library.

bug#7642: Build failure on NetBSD 5.0.2 on IA-32

[Glenn Morris]

Chong Yidong wrote:

> I've committed a patch reinstating the check for the Xaw3d library.

I think this can be closed then.

bug#7643: Build failure for SGI IRIX MIPS

[Chong Yidong]

Nelson H. F. Beebe reports a build failure of the 23.2.92 pretest on SGI
IRIX MIPS.

The last Emacs version to build ok was 21.3 in January 2004, so this
appears to be a long-standing bug.

> On IRIX, compilation fails in src/process.c like this:
>
> 	cc-1367 c89: ERROR File = process.c, Line = 2431
> 	  A pointer to an incomplete class type is not allowed.
>
> 		uint16_t *ip6 = (uint16_t *) &sin6->sin6_addr;
> 					      ^
>
> 	cc-1367 c89: ERROR File = process.c, Line = 2432
> 	  A pointer to an incomplete class type is not allowed.
>
> 		len = sizeof (sin6->sin6_addr)/2 + 1;
> 			      ^
>
> 	cc-1367 c89: ERROR File = process.c, Line = 2435
> 	  A pointer to an incomplete class type is not allowed.
>
> 		p->contents[--len] = make_number (ntohs (sin6->sin6_port));
> 									 ^
>
> 	cc-1070 c89: ERROR File = process.c, Line = 2489
> 	  The indicated type is incomplete.
>
> 		  return sizeof (struct sockaddr_in6);
> 				 ^
>
> 	cc-1367 c89: ERROR File = process.c, Line = 2546
> 	  A pointer to an incomplete class type is not allowed.
>
> 		  uint16_t *ip6 = (uint16_t *)&sin6->sin6_addr;
> 					       ^
>
> 	cc-1367 c89: ERROR File = process.c, Line = 2547
> 	  A pointer to an incomplete class type is not allowed.
>
> 		  len = sizeof (sin6->sin6_addr) + 1;
> 				^
>
> 	cc-1367 c89: ERROR File = process.c, Line = 2549
> 	  A pointer to an incomplete class type is not allowed.
>
> 		  sin6->sin6_port = htons (i);
> 		  ^
>
> 	cc-1070 c89: ERROR File = process.c, Line = 4388
> 	  The indicated type is incomplete.
>
> 	      struct sockaddr_in6 in6;
> 				  ^
>
> 	8 errors detected in the compilation of "process.c".

bug#7643: Build failure for SGI IRIX MIPS

[Chong Yidong]

> cc-1367 c89: ERROR File = process.c, Line = 2431
>   A pointer to an incomplete class type is not allowed.
>
>         uint16_t *ip6 = (uint16_t *) &sin6->sin6_addr;
> ...
> cc-1367 c89: ERROR File = process.c, Line = 2435
>   A pointer to an incomplete class type is not allowed.
>
>         p->contents[--len] = make_number (ntohs (sin6->sin6_port));

This is a bit of a long shot, but could you check if this maching has
uint16_t defined?

Also, what is the definition of sockaddr_in6 in netinet/in.h and the
definition of ntohs in arpa/inet.h?  On GNU/Linux, they are

struct sockaddr_in6
  {
    __SOCKADDR_COMMON (sin6_);
    in_port_t sin6_port;	/* Transport layer port # */
    uint32_t sin6_flowinfo;	/* IPv6 flow information */
    struct in6_addr sin6_addr;	/* IPv6 address */
    uint32_t sin6_scope_id;	/* IPv6 scope-id */
  };

uint16_t ntohs(uint16_t netshort);

but maybe they are defined differently in IRIX.

bug#7643: Build failure for SGI IRIX MIPS

[Glenn Morris]

I am afraid that without more input from you or someone else using IRIX
who can reproduce this, nothing can be done.

At a guess, maybe you need to compile with -DINET6, in which case a
patch like the following might fix it. But I don't see the point in
installing this without any testing.

If you can reply with the contents of netinet/in.h on your system, that
might help, and we can reopen this if needed.

*** src/process.c	2011-09-09 01:06:52 +0000
--- src/process.c	2011-10-07 21:42:30 +0000
***************
*** 39,44 ****
--- 39,51 ----
  
  #include <sys/socket.h>
  #include <netdb.h>
+ 
+ /* Some (which?) IRIX 6.5 hide IPv6 stuff in in.h behind #ifdef INET6.
+    See bug#7643.  */
+ #if defined(AF_INET6) && defined(IRIX6_5)
+ #define INET6
+ #endif
+ 
  #include <netinet/in.h>
  #include <arpa/inet.h>