* bug#7642: Build failure on NetBSD 5.0.2 on IA-32 [not found] <CMM.0.95.0.1292278169.beebe@psi.math.utah.edu> @ 2010-12-15 1:39 ` Chong Yidong 2010-12-15 8:29 ` Glenn Morris ` (2 more replies) 2010-12-15 1:41 ` bug#7643: Build failure for SGI IRIX MIPS Chong Yidong 1 sibling, 3 replies; 14+ messages in thread From: Chong Yidong @ 2010-12-15 1:39 UTC (permalink / raw) To: 7642 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7642: Build failure on NetBSD 5.0.2 on IA-32 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 2011-01-27 20:51 ` Chong Yidong 2 siblings, 1 reply; 14+ messages in thread From: Glenn Morris @ 2010-12-15 8:29 UTC (permalink / raw) To: Chong Yidong; +Cc: 7642 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? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7642: Build failure on NetBSD 5.0.2 on IA-32 2010-12-15 8:29 ` Glenn Morris @ 2010-12-16 1:38 ` Chong Yidong 0 siblings, 0 replies; 14+ messages in thread From: Chong Yidong @ 2010-12-16 1:38 UTC (permalink / raw) To: Nelson H. F. Beebe; +Cc: 7642 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7642: Build failure on NetBSD 5.0.2 on IA-32 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 17:03 ` Nelson H. F. Beebe 2010-12-17 14:32 ` Chong Yidong ` (2 more replies) 2011-01-27 20:51 ` Chong Yidong 2 siblings, 3 replies; 14+ messages in thread From: Nelson H. F. Beebe @ 2010-12-16 17:03 UTC (permalink / raw) To: Chong Yidong, Glenn Morris, 7642; +Cc: bug-gnu-emacs, 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/ - ------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7642: Build failure on NetBSD 5.0.2 on IA-32 2010-12-16 17:03 ` Nelson H. F. Beebe @ 2010-12-17 14:32 ` Chong Yidong 2011-01-16 3:23 ` Glenn Morris 2011-01-16 3:25 ` Glenn Morris 2 siblings, 0 replies; 14+ messages in thread From: Chong Yidong @ 2010-12-17 14:32 UTC (permalink / raw) To: Nelson H. F. Beebe; +Cc: enami tsugutomo, 7642, 6190 "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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7642: Build failure on NetBSD 5.0.2 on IA-32 2010-12-16 17:03 ` Nelson H. F. Beebe 2010-12-17 14:32 ` Chong Yidong @ 2011-01-16 3:23 ` Glenn Morris 2011-01-16 3:25 ` Glenn Morris 2 siblings, 0 replies; 14+ messages in thread From: Glenn Morris @ 2011-01-16 3:23 UTC (permalink / raw) To: Nelson H. F. Beebe; +Cc: Chong Yidong, 7642 "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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7642: Build failure on NetBSD 5.0.2 on IA-32 2010-12-16 17:03 ` Nelson H. F. Beebe 2010-12-17 14:32 ` Chong Yidong 2011-01-16 3:23 ` Glenn Morris @ 2011-01-16 3:25 ` Glenn Morris 2 siblings, 0 replies; 14+ messages in thread From: Glenn Morris @ 2011-01-16 3:25 UTC (permalink / raw) To: Nelson H. F. Beebe; +Cc: Chong Yidong, 7642 "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? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7642: Build failure on NetBSD 5.0.2 on IA-32 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 17:03 ` Nelson H. F. Beebe @ 2011-01-27 20:51 ` Chong Yidong 2011-01-28 18:15 ` Glenn Morris 2 siblings, 1 reply; 14+ messages in thread From: Chong Yidong @ 2011-01-27 20:51 UTC (permalink / raw) To: 7642 > > 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7642: Build failure on NetBSD 5.0.2 on IA-32 2011-01-27 20:51 ` Chong Yidong @ 2011-01-28 18:15 ` Glenn Morris 0 siblings, 0 replies; 14+ messages in thread From: Glenn Morris @ 2011-01-28 18:15 UTC (permalink / raw) To: 7642-done Chong Yidong wrote: > I've committed a patch reinstating the check for the Xaw3d library. I think this can be closed then. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7643: Build failure for SGI IRIX MIPS [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 1:41 ` Chong Yidong 2011-01-08 20:43 ` Chong Yidong 1 sibling, 1 reply; 14+ messages in thread From: Chong Yidong @ 2010-12-15 1:41 UTC (permalink / raw) To: 7643 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". ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7643: Build failure for SGI IRIX MIPS 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 0 siblings, 1 reply; 14+ messages in thread From: Chong Yidong @ 2011-01-08 20:43 UTC (permalink / raw) To: Nelson H. F. Beebe; +Cc: 7643 > 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7643: Build failure for SGI IRIX MIPS 2011-01-08 20:43 ` Chong Yidong @ 2011-10-10 17:54 ` Glenn Morris 0 siblings, 0 replies; 14+ messages in thread From: Glenn Morris @ 2011-10-10 17:54 UTC (permalink / raw) To: 7643-done 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9684: Emacs 23.3 and 24.0.90 don't build on IRIX 6.5 @ 2011-10-06 14:19 Rainer Orth 2011-10-07 0:49 ` Glenn Morris 0 siblings, 1 reply; 14+ messages in thread From: Rainer Orth @ 2011-10-06 14:19 UTC (permalink / raw) To: 9684 I've recently tried to build current emacs versions on IRIX 6.5 (6.5.30f, actually), but always failed in the same way. The latest attempt was like this: * Configure emacs 24.0.90 with /vol/src/gnu/emacs/emacs-24.0.90/configure --prefix=/vol/gnu --infodir=/vol/gnu/info --mandir=/vol/gnu/man --libexecdir=/vol/gnu/lib --localstatedir=/vol/gnu/share/emacs/var --with-xpm=no --with-jpeg=no --with-png=no --with-gif=no --with-tiff=no * Build it with gcc 4.6.0 with make -j8. The C part of the build complete successfully, but then it fails like this: Dumping under the name emacs 41988 pure bytes used cd ../lisp; make -w --jobserver-fds=3,4 - --jobserver-fds=3,4 -j compile-first EMACS=/vol/obj/gnu/emacs/emacs-24.0.90/src/bootstrap-emacs make[2]: Entering directory `/vol/obj/gnu/emacs/emacs-24.0.90/lisp' make[2]: Nothing to be done for `compile-first'. make[2]: Leaving directory `/vol/obj/gnu/emacs/emacs-24.0.90/lisp' cd ../lisp; make -w --jobserver-fds=3,4 - --jobserver-fds=3,4 -j autoloads EMACS=/vol/obj/gnu/emacs/emacs-24.0.90/src/bootstrap-emacs make[2]: Entering directory `/vol/obj/gnu/emacs/emacs-24.0.90/lisp' Compiling /vol/src/gnu/emacs/emacs-24.0.90/src/../lisp/emacs-lisp/backquote.el emacs: Invalid function: make-local-variable make[2]: *** [compile-onefile] Error 1 make[2]: Leaving directory `/vol/obj/gnu/emacs/emacs-24.0.90/lisp' I have no idea what might cause this; emacs 23.2 built fine and mostly works. For emacs 23.3, I tried several variations: * build with gcc 4.4.2 * build with gcc -g3 -O0 instead of the default -g -O2 * build with SGI MIPSpro cc 7.4.4m None of those makes a difference. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9684: Emacs 23.3 and 24.0.90 don't build on IRIX 6.5 2011-10-06 14:19 bug#9684: Emacs 23.3 and 24.0.90 don't build on IRIX 6.5 Rainer Orth @ 2011-10-07 0:49 ` Glenn Morris 2011-10-07 9:20 ` bug#7643: " Rainer Orth 0 siblings, 1 reply; 14+ messages in thread From: Glenn Morris @ 2011-10-07 0:49 UTC (permalink / raw) To: Rainer Orth; +Cc: 9684 If you have an SGI IRIX, maybe you could help out with http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7643 ? The original submitter never replied. Though presumably you don't see that problem since the C build completed for you (also I'm not sure if you are using the same kind of system). Thanks! ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7643: bug#9684: Emacs 23.3 and 24.0.90 don't build on IRIX 6.5 2011-10-07 0:49 ` Glenn Morris @ 2011-10-07 9:20 ` Rainer Orth 2011-10-07 18:48 ` bug#7643: Build failure for SGI IRIX MIPS Glenn Morris 0 siblings, 1 reply; 14+ messages in thread From: Rainer Orth @ 2011-10-07 9:20 UTC (permalink / raw) To: Glenn Morris; +Cc: 7643 [Cc'ing to the correct bug.] Glenn Morris <rgm@gnu.org> writes: > If you have an SGI IRIX, maybe you could help out with > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7643 ? > > The original submitter never replied. I can at least try... > Though presumably you don't see that problem since the C build completed > for you (also I'm not sure if you are using the same kind of system). I fear that's exactly the problem: IPv6 support was only added in a later update of IRIX 6.5 (don't recall exactly which one), so without knowing what Nelson is (was) running, it's hard to tell. Maybe emacs assumes IPv6 support unconditionally (or the test was insufficient)? I did have various problems building 23.3 on 6.5.30 myself, but nothing related to IPv6. I didn't try with cc, though. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7643: Build failure for SGI IRIX MIPS 2011-10-07 9:20 ` bug#7643: " Rainer Orth @ 2011-10-07 18:48 ` Glenn Morris 2011-10-07 19:18 ` Glenn Morris 0 siblings, 1 reply; 14+ messages in thread From: Glenn Morris @ 2011-10-07 18:48 UTC (permalink / raw) To: Rainer Orth; +Cc: 7643 Rainer Orth wrote: > I fear that's exactly the problem: IPv6 support was only added in a > later update of IRIX 6.5 (don't recall exactly which one), so without > knowing what Nelson is (was) running, it's hard to tell. Maybe emacs > assumes IPv6 support unconditionally (or the test was insufficient)? Thanks for looking at this. However, all the relevant places in process.c seems to be inside #ifdef AF_INET6, where AF_INET6 is defined by the system headers, not by Emacs. So if IPv6 support is not present these sections should never be seen. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#7643: Build failure for SGI IRIX MIPS 2011-10-07 18:48 ` bug#7643: Build failure for SGI IRIX MIPS Glenn Morris @ 2011-10-07 19:18 ` Glenn Morris 0 siblings, 0 replies; 14+ messages in thread From: Glenn Morris @ 2011-10-07 19:18 UTC (permalink / raw) To: 7643; +Cc: Rainer Orth Web search suggests maybe some IRIXs need -DINET6? http://www.mail-archive.com/openpkg-users@openpkg.org/msg02606.html ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-10-10 17:54 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [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 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 2011-10-06 14:19 bug#9684: Emacs 23.3 and 24.0.90 don't build on IRIX 6.5 Rainer Orth 2011-10-07 0:49 ` Glenn Morris 2011-10-07 9:20 ` bug#7643: " Rainer Orth 2011-10-07 18:48 ` bug#7643: Build failure for SGI IRIX MIPS Glenn Morris 2011-10-07 19:18 ` Glenn Morris
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.