GNU bug report logs - #17339
[bug-gnu-emacs] emacs-24.3.90: big build report

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 17339 in the body.
You can then email your comments to 17339 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: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
To: bug-gnu-emacs <at> gnu.org
Cc: beebe <at> math.utah.edu
Subject: [bug-gnu-emacs] emacs-24.3.90: big build report
Date: Thu, 24 Apr 2014 15:07:16 -0600 (MDT)

I have a test lab with about 40 flavors of Unix running on current and
historical CPU architectures.  I have now done more than 70 build
attempts for the new emacs-24.3.90 release of 19-Apr-2014, and
happily, I can report success on most of them.  There remain a few
failures, and on some of the successful systems, I had to make
repeated tries to find option combinations that would produce a
successful build of emacs, including X11 support on all systems.

In NO CASE did I have to resort to editing any file from
emacs-24.3.90.

First, here is a brief list of systems for which I have successful
builds and installations; compiler choices, configure options and
environment variable settings are omitted, but I can supply them
offlist on request.

	--------------------------------------------------
	O/S version				CPU family
	--------------------------------------------------
	DragonFly 3.6				x86-64
	FreeBSD 9.1				x86
	FreeBSD 10.0				x86-64
	GNU/Linux ArchLinux			x86-64
	GNU/Linux Debian 6.0.9			x86-64
	GNU/Linux Debian 7.4			x86-64
	GNU/Linux Fedora 19			x86
	GNU/Linux Gentoo 2.2			Alpha
	GNU/Linux Gentoo 2.2			PowerPC-32
	GNU/Linux Gentoo 2.2			PowerPC-64
	GNU/Linux Gentoo 2.2			SPARC
	GNU/Linux Red Hat 5.10			IA-64
	GNU/Linux Red Hat 5.10			x86
	GNU/Linux Red Hat 5.10			x86-64
	GNU/Linux Red Hat 6.5			x86-64
	GNU/Linux Red Hat 7.0 beta		x86-64
	GNU/Linux Scientific Linux 6.5		x86-64
	GNU/Linux Slackware 14.0		x86-64
	GNU/Linux Ubuntu 12.04			x86
	GNU/Linux openSUSE 11.2			x86_64
	GNU/Linux openSUSE 12.3			x86_64
	GNU/Linux openSUSE 13.1			x86_64
	Mac OS X 10.5.8				PowerPC-32
	Mac OS X 10.7.5				x86-64
	MirBSD 10				x86
	OpenBSD 4.7				x86
	OpenBSD 5.1				x86
	OpenBSD 5.4				x86-64
	Solaris 10				SPARC
	Solaris 10				x86
	Solaris 10				x86-64
	Solaris 11				x86-64
	--------------------------------------------------

Here are the failing systems:

    GNU/Hurd x86:
	Compilation fails with

	process.c: In function 'handle_child_signal':
	process.c:6228:58: error: 'WCONTINUED' undeclared (first use in this function)
	    && child_status_changed (p->pid, &status, WUNTRACED | WCONTINUED))
								  ^
	process.c:6228:58: note: each undeclared identifier is reported only once for each function it appears in

	The symbol WCONTINUED is not defined in any file under /usr/include.

    NetBSD 5.0.2 x86:
	Compilation fails with

	    process.c: In function 'handle_child_signal':
	    process.c:6228:58: error: 'WCONTINUED' undeclared (first use in this function)
	That symbol is not found in any file under /usr/include.

    SGI IRIX 6.5 MIPS:
	/usr/local/bin/gcc -std=gnu99 -c -Demacs  -I. -I. -I../lib -I./../lib -g3 -O2  process.c
	process.c: In function `conv_sockaddr_to_lisp':
	process.c:2002: error: dereferencing pointer to incomplete type
	process.c:2003: error: dereferencing pointer to incomplete type
	process.c:2006: error: dereferencing pointer to incomplete type
	process.c: In function `get_lisp_to_sockaddr_size':
	process.c:2070: error: invalid application of `sizeof' to incomplete type `sockaddr_in6'
	process.c: In function `conv_lisp_to_sockaddr':
	process.c:2125: error: dereferencing pointer to incomplete type
	process.c:2126: error: dereferencing pointer to incomplete type
	process.c:2128: error: dereferencing pointer to incomplete type
	process.c: In function `server_accept_connection':
	process.c:4024: error: field `in6' has incomplete type

On all three systems, it looks like changes in emacs source code, or
perhaps the configure-time tests, will be needed.  I could see no
--enable-xxx, --disable-xxx, --with-xxx, or --without-xxx option that
would appear to affect the compilation issues in process.c.

Finally, here are problems for which I found workarounds:

(1) On several systems, linking failed with a missing symbol from the
    ImageMagick libraries:

	    undefined: PixelSetMagickColor

    The solution was to either

	    (a) add the --without-imagemagick option to configure

	    (b) build and install the latest ImageMagick release
		(6.8.9-0), and then retry the emacs build

    I've tried both approaches, and work in (b) is continuing.

(2) On NetBSD 6, configure tests for -lpng fail because that library does
    not exist; instead, the vendor provides only -lpng16.  I fooled the
    emacs configure script by creating this symlink:

		    /usr/local/lib/libpng.a: symbolic link to `/usr/pkg/lib/libpng16.a'

    so that -lpng is now found.

(3) On MirBSD, configure quits with the error

	    Emacs does not support `i386-unknown-mirbsd10' systems.

    The solution was to use the option --build=i386-unknown-openbsd4.9 in
    the configure step.  MirBSD is a derivative of OpenBSD 4.x, and that
    --build option trick has been necessary for a number of other software
    packages.

(4) On some systems (GNU/Linux on Alpha, SPARC, x86, PowerPC-32, and
    PowerPC-64), in the final "make install", I get this error very near
    the end:

	    /bin/bash: line 0: [: !=: unary operator expected
	    make[1]: Leaving directory '/local/build/bare/emacs-24.3.90/lib-src'

P.S. For a package of this size (410K lines of C, 1620K lines of
Lisp), the portability of emacs is wonderful!  My thanks go to the
great emacs development team who keep it building and working (almost)
everywhere.

-------------------------------------------------------------------------------
- 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 #8 received at 17339 <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: 17339 <at> debbugs.gnu.org
Subject: Re: bug#17339: [bug-gnu-emacs] emacs-24.3.90: big build report
Date: Tue, 29 Apr 2014 11:04:09 -0400

"Nelson H. F. Beebe" wrote:

> (1) On several systems, linking failed with a missing symbol from the
>     ImageMagick libraries:
>
> 	    undefined: PixelSetMagickColor

Please tell us what version of ImageMagick is installed on those systems.

> (2) On NetBSD 6, configure tests for -lpng fail because that library does
>     not exist; instead, the vendor provides only -lpng16.  I fooled the
>     emacs configure script by creating this symlink:
>
> 		    /usr/local/lib/libpng.a: symbolic link to `/usr/pkg/lib/libpng16.a'
>
>     so that -lpng is now found.

This has come up before; http://debbugs.gnu.org/11797#8 .
IMO it seems like a sub-optimal thing for NetBSD to do, but I guess they
have reasons.

Does: pkg-config --libs libpng

work on that system?

> (3) On MirBSD, configure quits with the error
>
> 	    Emacs does not support `i386-unknown-mirbsd10' systems.

I installed the following:

--- a/configure.ac	2014-04-13 22:51:08 +0000
+++ b/configure.ac	2014-04-29 14:49:11 +0000
@@ -505,7 +505,7 @@
   ;;
 
   ## OpenBSD ports
-  *-*-openbsd* )
+  *-*-openbsd* | *-*-mirbsd* )
     opsys=openbsd
   ;;

> (4) On some systems (GNU/Linux on Alpha, SPARC, x86, PowerPC-32, and
>     PowerPC-64), in the final "make install", I get this error very near
>     the end:
>
> 	    /bin/bash: line 0: [: !=: unary operator expected
> 	    make[1]: Leaving directory '/local/build/bare/emacs-24.3.90/lib-src'

I installed the following. If it does not fix it, please provide more
context from the build log.

--- a/lib-src/Makefile.in	2014-01-05 02:56:08 +0000
+++ b/lib-src/Makefile.in	2014-04-29 14:54:58 +0000
@@ -247,8 +247,8 @@
 	  chown ${gameuser} "$(DESTDIR)${gamedir}"; \
 	  chmod u=rwx,g=rwx,o=rx "$(DESTDIR)${gamedir}"; \
 	fi
-	if [ "`cd \"$(DESTDIR)${archlibdir}\" && /bin/pwd`" \
-             != "`cd ${srcdir} && /bin/pwd`" ]; then \
+	exp_archlibdir=`cd "$(DESTDIR)${archlibdir}" && /bin/pwd`; \
+	if [ "$$exp_archlibdir" != "`cd ${srcdir} && /bin/pwd`" ]; then \
 	  for file in ${SCRIPTS}; do \
 	    $(INSTALL_SCRIPT) ${srcdir}/$$file "$(DESTDIR)${archlibdir}/$$file"; \
 	  done ; \

Message #11 received at 17339 <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: 17339 <at> debbugs.gnu.org
Subject: Re: bug#17339: [bug-gnu-emacs] emacs-24.3.90: big build report
Date: Tue, 29 Apr 2014 11:15:33 -0400

"Nelson H. F. Beebe" wrote:

> 	process.c:6228:58: error: 'WCONTINUED' undeclared (first use in this function)
> 	    && child_status_changed (p->pid, &status, WUNTRACED | WCONTINUED))

I applied the following:

*** src/process.c	2014-04-16 13:27:28 +0000
--- src/process.c	2014-04-29 15:12:36 +0000
***************
*** 6225,6231 ****
        int status;
  
        if (p->alive
! 	  && child_status_changed (p->pid, &status, WUNTRACED | WCONTINUED))
  	{
  	  /* Change the status of the process that was found.  */
  	  p->tick = ++process_tick;
--- 6225,6235 ----
        int status;
  
        if (p->alive
! #ifndef WCONTINUED
!           && child_status_changed (p->pid, &status, WUNTRACED))
! #else
!           && child_status_changed (p->pid, &status, WUNTRACED | WCONTINUED))
! #endif
  	{
  	  /* Change the status of the process that was found.  */
  	  p->tick = ++process_tick;

Message #14 received at 17339 <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: 17339 <at> debbugs.gnu.org
Subject: Re: bug#17339: [bug-gnu-emacs] emacs-24.3.90: big build report
Date: Thu, 01 May 2014 17:59:48 -0400

Glenn Morris wrote:

> "Nelson H. F. Beebe" wrote:
[...]
>> (2) On NetBSD 6, configure tests for -lpng fail because that library does
>>     not exist; instead, the vendor provides only -lpng16.  I fooled the
>>     emacs configure script by creating this symlink:
>>
>> 		    /usr/local/lib/libpng.a: symbolic link to `/usr/pkg/lib/libpng16.a'
>>
>>     so that -lpng is now found.
>
> This has come up before; http://debbugs.gnu.org/11797#8 .

I applied the following:

--- a/configure.ac	2014-04-29 14:49:11 +0000
+++ b/configure.ac	2014-05-01 21:57:27 +0000
@@ -3101,8 +3101,15 @@
   fi
 
   if test "${HAVE_PNG}" = "yes"; then
-    AC_DEFINE(HAVE_PNG, 1, [Define to 1 if you have the png library (-lpng).])
-    LIBPNG="-lpng -lz -lm"
+    AC_DEFINE(HAVE_PNG, 1, [Define to 1 if you have the png library.])
+
+    dnl Some systems, eg NetBSD 6, only provide eg "libpng16", not "libpng".
+    lpng=`libpng-config --libs 2> /dev/null`
+    case $lpng in
+      -l*) : ;;
+      *) lpng="-lpng" ;;
+    esac
+    LIBPNG="$lpng -lz -lm"
 
     AC_CHECK_DECL(png_longjmp,
       [],
@@ -4976,7 +4983,7 @@
 echo "  Does Emacs use -ljpeg?                                  ${HAVE_JPEG}"
 echo "  Does Emacs use -ltiff?                                  ${HAVE_TIFF}"
 echo "  Does Emacs use a gif library?                           ${HAVE_GIF} $LIBGIF"
-echo "  Does Emacs use -lpng?                                   ${HAVE_PNG}"
+echo "  Does Emacs use a png library?                           ${HAVE_PNG} $LIBPNG"
 echo "  Does Emacs use -lrsvg-2?                                ${HAVE_RSVG}"
 echo "  Does Emacs use imagemagick?                             ${HAVE_IMAGEMAGICK}"
 

Message #17 received at 17339 <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: 17339 <at> debbugs.gnu.org
Subject: Re: bug#17339: [bug-gnu-emacs] emacs-24.3.90: big build report
Date: Thu, 01 May 2014 18:14:52 -0400

"Nelson H. F. Beebe" wrote:

>     SGI IRIX 6.5 MIPS:
> 	/usr/local/bin/gcc -std=gnu99 -c -Demacs  -I. -I. -I../lib -I./../lib -g3 -O2  process.c
> 	process.c: In function `conv_sockaddr_to_lisp':
> 	process.c:2002: error: dereferencing pointer to incomplete type
> 	process.c:2003: error: dereferencing pointer to incomplete type
> 	process.c:2006: error: dereferencing pointer to incomplete type
> 	process.c: In function `get_lisp_to_sockaddr_size':
> 	process.c:2070: error: invalid application of `sizeof' to incomplete type `sockaddr_in6'
> 	process.c: In function `conv_lisp_to_sockaddr':
> 	process.c:2125: error: dereferencing pointer to incomplete type
> 	process.c:2126: error: dereferencing pointer to incomplete type
> 	process.c:2128: error: dereferencing pointer to incomplete type
> 	process.c: In function `server_accept_connection':
> 	process.c:4024: error: field `in6' has incomplete type

IIUC, this is a failure to define the "sockaddr_in6" structure.
This is odd, because it is allegedly

http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/IRIX_NetPG/sgi_html/ch03.html

defined in netinet/in.h, which process.c includes.

Can you find which .h file defines it on that system?
Or send netinet/in.h?

This is not a big deal, because we have had persistent problems with
SGI IRIX (eg http://debbugs.gnu.org/9684), and have dropped support for
it in Emacs 24.5.


In fact I see this looks like the same issue as http://debbugs.gnu.org/7643,
which you reported but never followed up to
I suggested something to try in

http://debbugs.gnu.org/7643#24

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 15110 <at> debbugs.gnu.org, 17339 <at> debbugs.gnu.org
Subject: Re: build error: WCONTINUED undeclared
Date: Sat, 03 May 2014 13:17:06 -0700

[Message part 1 (text/plain, inline)]

I noticed that lib-src and src were solving the same problem in two 
different ways, which can't be right, so I applied the attached further 
patch to make it consistent, as emacs-24 bzr 117055.

[WCONTINUED.diff (text/plain, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 17339 <at> debbugs.gnu.org
Cc: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
Subject: Re:  "undefined: PixelSetMagickColor" when building emacs-24.3.90
Date: Sat, 03 May 2014 14:10:53 -0700

> Please tell us what version of ImageMagick is installed on those systems.

I went through the old ImageMagick versions (not a pleasant exercise) 
and found that PixelSetMagickColor was introduced in ImageMagick 6.3.5, 
dated September 2007.  The simplest fix is to require 6.3.5 or later, so 
I did that in emacs-24 bzr 117056.  If someone wants to port the Emacs 
source code to older versions of ImageMagick, please feel free.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 17339 <at> debbugs.gnu.org
Subject: Re: SGI IRIX 6.5 in emacs-24.3.90: big build report
Date: Sat, 03 May 2014 14:28:37 -0700

As luck would have it, I ported the emacs-24 branch to SGI IRIX 6.5 on 
April 13, the day after the emacs-24.3.90 pretest tarball was made.  I 
ran into the problem with sockaddr_in6 and fixed it in emacs-24 bzr 
116961 by tweaking src/conf_post.h to #define INET6 on IRIX 6.5.  So 
this should be fixed in the next pretest.  (This also should fix 
Bug#7643, which was marked done a while ago, I don't know why.)

The port requires IRIX cc, unfortunately.  I did not get undump to work 
with the old GCC installed at Utah.  I assume it's a simple fix for 
someone versed in undumping on IRIX, which I am not.  As far as I know 
this is the only remaining issue in Bug#17339.

Previous Next

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