Patch for build failure on OS X (under review)

Patch for build failure on OS X (under review)

[Andrew Schwartzmeyer]

[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]

When building under Homebrew with the options 'brew install emacs --use-git-head --HEAD --cocoa --srgb --with-gnutls' (that is, build off master as of Mon May  5 19:31:51 PDT 2014, Cocoa build with sRGB colors, link to GnuTLS library, the following build error was encountered:

> gcc-4.8 -std=gnu99 -c  -Demacs  -I. -I. -I../lib -I./../lib   -I/usr/X11/include      -I/usr/include/libxml2          -MMD -MF deps/image.d -MP -I/usr/local/Cellar/libtasn1/3.4/include -I/usr/local/Cellar/nettle/2.7.1/include -I/usr/local/Cellar/gnutls/3.2.13/include     -g3 -O2  image.c
> image.c: In function 'png_load_body':
> image.c:5919:37: error: 'frame_background' undeclared (first use in this function)
>     fn_png_set_background (png_ptr, &frame_background,
>                                      ^
> image.c:5919:37: note: each undeclared identifier is reported only once for each function it appears in
> make[1]: *** [image.o] Error 1
> make: *** [src] Error 2
> ==> Configuration
> HOMEBREW_VERSION: 0.9.5
> HEAD: b10c09b1746cd5673bff4e40c4485cb266b1932b
> CPU: quad-core 64-bit ivybridge
> OS X: 10.9.2-x86_64
> Xcode: 5.1.1
> CLT: 5.1.0.0.1.1396320587
> X11: 2.7.5 => /opt/X11
> ==> ENV
> HOMEBREW_CC: gcc-4.8
> HOMEBREW_CXX: g++-4.8
> CMAKE_PREFIX_PATH: /usr/local
> CMAKE_INCLUDE_PATH: /usr/include/libxml2:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers
> CMAKE_LIBRARY_PATH: /System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries
> PKG_CONFIG_PATH: /usr/local/opt/libtasn1/lib/pkgconfig:/usr/local/opt/nettle/lib/pkgconfig:/usr/local/opt/gnutls/lib/pkgconfig
> PKG_CONFIG_LIBDIR: /usr/lib/pkgconfig:/usr/local/Library/ENV/pkgconfig/10.9
> ACLOCAL_PATH: /usr/local/share/aclocal
> PATH: /usr/local/Library/ENV/4.3:/usr/local/opt/autoconf/bin:/usr/local/opt/automake/bin:/usr/local/opt/pkg-config/bin:/usr/local/opt/libtasn1/bin:/usr/local/opt/nettle/bin:/usr/local/opt/gnutls/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/opt/gcc/bin
> 
> Error: emacs HEAD did not build

Note that the exact same error happens when building with the system clang compiler.

Inspection of src/image.c revealed that in certain cases, an undefined variable reference occurred. This was due to a preprocessor #if/endif block (lines 5906 to 5917) in which the variable (png_color_16 frame_background;) was created, and a function (fn_png_set_background) after said block that needed used said variable. Here is where I am unsure: should the function be called after the block (necessitating making the variable before the block), or should the function be called inside the block? This patch does the former, as I assumed.

> diff --git a/src/image.c b/src/image.c
> index c26c0db..b4582d2 100644
> --- a/src/image.c
> +++ b/src/image.c
> @@ -5903,9 +5903,11 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c)
>  	{
>  	  /* We use the current frame background, ignoring any default
>  	     background color set by the image.  */
> +
> +	  png_color_16 frame_background;
> +
>  #if defined (HAVE_X_WINDOWS) || defined (HAVE_NTGUI)
>  	  XColor color;
> -	  png_color_16 frame_background;
>  
>  	  color.pixel = FRAME_BACKGROUND_PIXEL (f);
>  	  x_query_color (f, &color);

I made this from a git diff; if need be, I can figure out Bazaar and send a patch in the documented format. If there’s a better way to do this, please let me know.

Cheers,

Andrew Schwartzmeyer

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: Patch for build failure on OS X (under review)

[Alp Aker]

[-- Attachment #1: Type: text/plain, Size: 85 bytes --]

Unfortunately, that is not the correct fix.  The code that's causing the
error is in

[-- Attachment #2: Type: text/html, Size: 117 bytes --]

Re: Patch for build failure on OS X (under review)

[Alp Aker]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

[Apologies for the premature send on the previous.]

Unfortunately, that's not the correct fix.  The code that's causing the
error shouldn't be compiled at all on an NS build; it's in a large block
that's conditioned on HAVE_PNG, which the NS build expects to be false, as
that port supplies its on version of png_load().

The current incorrect configuration behavior appears to have been caused by:

revno: 117059
fixes bug: http://debbugs.gnu.org/17339
committer: Paul Eggert <eggert@cs.ucla.edu>
branch nick: trunk
timestamp: Sun 2014-05-04 14:28:08 -0700
message:
  Consult libpng-config more consistently.

  This is mainly for simplicity, but it should also avoid
  some future problems like the ones we recently had with NetBSD.
  * configure.ac (LIBPNG): Configure after LIBZ.  Use libpng-config
  for cflags, too.  Append -lz if we're not already doing that with
  LIBZ.  Do not bother appending -lm, since we always append that.
  Coalesce some duplicate code.
  * src/Makefile.in (PNG_CFLAGS): New var.
  (ALL_CFLAGS): Use it.
  * src/image.c [HAVE_PNG]: Don't worry about <libpng/png.h>, as
  CFLAGS now handles this.

[-- Attachment #2: Type: text/html, Size: 1408 bytes --]

Re: Patch for build failure on OS X (under review)

[Paul Eggert]

On 05/06/2014 01:10 PM, Alp Aker wrote:
> The code that's causing the error shouldn't be compiled at all on an 
> NS build; it's in a large block that's conditioned on HAVE_PNG, which 
> the NS build expects to be false, as that port supplies its on version 
> of png_load().

Ah, sorry, I didn't know HAVE_NS and HAVE_PNG were supposed to be 
mutually exclusive.  In trunk bzr 117068 I installed a patch that I hope 
fixes things, though I don't have easy access to OS X and have not 
tested it there.  Please give it a try.

Re: Patch for build failure on OS X (under review)

[Harald Hanche-Olsen]

[Paul Eggert <eggert@cs.ucla.edu> (2014-05-06 21:16:32 UTC)]

> On 05/06/2014 01:10 PM, Alp Aker wrote:
> > The code that's causing the error shouldn't be compiled at all on an
> > NS build; it's in a large block that's conditioned on HAVE_PNG, which
> > the NS build expects to be false, as that port supplies its on version
> > of png_load().
> 
> Ah, sorry, I didn't know HAVE_NS and HAVE_PNG were supposed to be
> mutually exclusive. In trunk bzr 117068 I installed a patch that I
> hope fixes things, though I don't have easy access to OS X and have
> not tested it there. Please give it a try.

It fails in configure for me:

  configure: error: The following required libraries were not found:
       libjpeg libgif/libungif
  Maybe some development libraries/packages are missing?

This is with just --with-ns, which used to work before.

– Harald