From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: Chong Yidong <cyd@stupidchicken.com>, Glenn Morris <rgm@gnu.org>,
7642@debbugs.gnu.org
Cc: bug-gnu-emacs@gnu.org, beebe@math.utah.edu
Subject: bug#7642: Build failure on NetBSD 5.0.2 on IA-32
Date: Thu, 16 Dec 2010 10:03:57 -0700 (MST) [thread overview]
Message-ID: <CMM.0.95.0.1292519036.beebe@psi.math.utah.edu> (raw)
In-Reply-To: <877hfbx19k.fsf@stupidchicken.com>
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/ -
-------------------------------------------------------------------------------
next prev parent reply other threads:[~2010-12-16 17:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CMM.0.95.0.1292278169.beebe@psi.math.utah.edu>
2010-12-15 1:39 ` bug#7642: Build failure on NetBSD 5.0.2 on IA-32 Chong Yidong
2010-12-15 8:29 ` Glenn Morris
2010-12-16 1:38 ` Chong Yidong
2010-12-16 17:03 ` Nelson H. F. Beebe [this message]
2010-12-17 14:32 ` Chong Yidong
2011-01-16 3:23 ` Glenn Morris
2011-01-16 3:25 ` Glenn Morris
2011-01-27 20:51 ` Chong Yidong
2011-01-28 18:15 ` Glenn Morris
2010-12-15 1:41 ` bug#7643: Build failure for SGI IRIX MIPS Chong Yidong
2011-01-08 20:43 ` Chong Yidong
2011-10-10 17:54 ` Glenn Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CMM.0.95.0.1292519036.beebe@psi.math.utah.edu \
--to=beebe@math.utah.edu \
--cc=7642@debbugs.gnu.org \
--cc=bug-gnu-emacs@gnu.org \
--cc=cyd@stupidchicken.com \
--cc=rgm@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.