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