GNU bug report logs - #7642
Build failure on NetBSD 5.0.2 on IA-32

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7642 in the body.
You can then email your comments to 7642 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Build failure on NetBSD 5.0.2 on IA-32
Date: Wed, 15 Dec 2010 09:39:35 +0800

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

Message #8 received at 7642 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7642 <at> debbugs.gnu.org
Subject: Re: bug#7642: Build failure on NetBSD 5.0.2 on IA-32
Date: Wed, 15 Dec 2010 03:29:26 -0500

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?

Message #11 received at 7642 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, 7642 <at> debbugs.gnu.org
Subject: Re: bug#7642: Build failure on NetBSD 5.0.2 on IA-32
Date: Thu, 16 Dec 2010 09:38:43 +0800

Glenn Morris <rgm <at> 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.

Message #14 received at 7642 <at> debbugs.gnu.org (full text, mbox):

From: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
To: Chong Yidong <cyd <at> stupidchicken.com>, Glenn Morris <rgm <at> gnu.org>,
	7642 <at> debbugs.gnu.org
Cc: bug-gnu-emacs <at> gnu.org, beebe <at> math.utah.edu
Subject: Re: bug#7642: Build failure on NetBSD 5.0.2 on IA-32
Date: Thu, 16 Dec 2010 10:03:57 -0700 (MST)

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 <at> math.utah.edu  -
- 155 S 1400 E RM 233                       beebe <at> acm.org  beebe <at> computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

Message #20 received at 7642 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, enami tsugutomo <tsugutomo.enami <at> jp.sony.com>,
	7642 <at> debbugs.gnu.org, 6190 <at> debbugs.gnu.org
Subject: Re: bug#7642: Build failure on NetBSD 5.0.2 on IA-32
Date: Fri, 17 Dec 2010 22:32:17 +0800

"Nelson H. F. Beebe" <beebe <at> 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

Message #23 received at 7642 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 7642 <at> debbugs.gnu.org
Subject: Re: bug#7642: Build failure on NetBSD 5.0.2 on IA-32
Date: Sat, 15 Jan 2011 22:23:06 -0500

"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.

Message #26 received at 7642 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 7642 <at> debbugs.gnu.org
Subject: Re: bug#7642: Build failure on NetBSD 5.0.2 on IA-32
Date: Sat, 15 Jan 2011 22:25:49 -0500

"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?

Message #29 received at 7642 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: 7642 <at> debbugs.gnu.org
Subject: Re: Build failure on NetBSD 5.0.2 on IA-32
Date: Thu, 27 Jan 2011 15:51:49 -0500

> > 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.

Message #34 received at 7642-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 7642-done <at> debbugs.gnu.org
Subject: Re: bug#7642: Build failure on NetBSD 5.0.2 on IA-32
Date: Fri, 28 Jan 2011 13:15:38 -0500

Chong Yidong wrote:

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

I think this can be closed then.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.