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

From: "Nelson H. F. Beebe" <[email-masked]>
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: [email-masked]  -
- 155 S 1400 E RM 233                       [email-masked]  [email-masked] -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------