GNU bug report logs - #17289
24.4.50; Build failure (Fedora 20)

Previous Next

Package: emacs;

Reported by: Mattia Ziulu <mziulu <at> gmail.com>

Date: Fri, 18 Apr 2014 06:35:02 UTC

Severity: normal

Found in version 24.4.50

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#17289: closed (24.4.50; Build failure (Fedora 20))
Date: Sat, 19 Apr 2014 17:59:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Sat, 19 Apr 2014 10:58:24 -0700
with message-id <5352B940.3090306 <at> cs.ucla.edu>
and subject line Re: bug#17289: 24.4.50; Build failure (Fedora 20)
has caused the debbugs.gnu.org bug report #17289,
regarding 24.4.50; Build failure (Fedora 20)
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
17289: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17289
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Mattia Ziulu <mziulu <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; Build failure (Fedora 20)
Date: Fri, 18 Apr 2014 08:33:51 +0200
I've been unable to build emacs, tracking the official git repo,
since Monday 14. I usually create a new 'build' directory inside the
clone and from there issue the configure command with the flags reported
below.

../configure --prefix=/opt/mattia --enable-link-time-optimization
--with-file-notification=inotify

This is the compile error:

gcc -std=gnu99 -Demacs  -I. -I../../src -I../lib -I../../src/../lib   -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -I/usr/include/freetype2   -I/usr/include/alsa    -I/usr/include/libxml2  -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include    -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -pthread -I/usr/include/gconf/2 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -I/usr/include/freetype2  -I/usr/include/freetype2    -MMD -MF deps/.d -MP -I/usr/include/p11-kit-1     -g3 -O2 -flto=4 -flto=4  -Wl,-znocombreloc   \
  -o temacs  vm-limit.o dispnew.o frame.o scroll.o xdisp.o menu.o xmenu.o window.o charset.o coding.o category.o ccl.o character.o chartab.o bidi.o cm.o term.o terminal.o xfaces.o xterm.o xfns.o xselect.o xrdb.o xsmfns.o xsettings.o gtkutil.o emacsgtkfixed.o dbusbind.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o font.o print.o lread.o syntax.o unexelf.o bytecode.o process.o gnutls.o callproc.o region-cache.o sound.o atimer.o doprnt.o intervals.o textprop.o composite.o xml.o inotify.o profiler.o decompress.o     xfont.o ftfont.o xftfont.o ftxfont.o  fontset.o fringe.o image.o   terminfo.o lastfile.o      ../lib/libgnu.a       -ltiff -ljpeg -lpng -lz -lm -lgif -lXpm -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0  -lSM -lICE -lX11 -lXrender -lXft  -lasound    -lacl    -lrt  -ldbus-1   -lXrandr  -lXinerama  -lxml2  -lgpm   -ltinfo  -lgio-2.0 -lgobject-2.0 -lglib-2.0  -lgconf-2 -lglib-2.0  -lgobject-2.0 -lglib-2.0  -lselinux -lfreetype  -lfontconfig -lfreetype    -lgnutls  -lpthread   -lm -lz
/tmp/ccbvZSZ2.ltrans14.ltrans.o: In function `x_menu_wait_for_event.isra.6':
/opt/mattia/usr/local/src/emacs/build/src/../../src/xmenu.c:260: undefined reference to `xg_select'
collect2: error: ld returned 1 exit status
make[2]: *** [temacs] Error 1
make[2]: Leaving directory `/opt/mattia/usr/local/src/emacs/build/src'
make[1]: *** [src] Error 2
make[1]: Leaving directory `/opt/mattia/usr/local/src/emacs/build'
make: *** [bootstrap] Error 2


A GTK2 build does not present the error (as expected).

----

Configured features:
XPM JPEG TIFF GIF PNG SOUND GPM DBUS GCONF GSETTINGS NOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix


[Message part 3 (message/rfc822, inline)]
From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Jan D." <jan.h.d <at> swipnet.se>, Mattia Ziulu <mziulu <at> gmail.com>, 
 17289-done <at> debbugs.gnu.org
Subject: Re: bug#17289: 24.4.50; Build failure (Fedora 20)
Date: Sat, 19 Apr 2014 10:58:24 -0700
Jan D. wrote:

> I though the point was to let CFLAGS
> and LIBS to accumulate so we can catch conflicts early.  If for example,
> Glib and librsvg has a conflict, it would be caught at configure time,
> probably by ignoring one of the libs, and still let Emacs be built.

That may have been the point originally, but 'configure' long ago lost 
it; even in emacs-24 libraries sometimes accumulate and sometimes do not.

The emacs-24 approach has a different problem: because some libraries 
accumulate, later tests report answers that are incorrect for non-Emacs 
applications such as etags which do not necessarily link to these 
libraries.  I ran into one of these problems with IRIX, and installed a 
small hack-atop-a-hack in emacs-24 to fix that one little problem, but 
in the trunk I am looking for a cleaner solution.  The basic idea is 
that each test should be try to be independent from the others, and that 
any necessary dependencies be indicated for the test.

I had tested the trunk change myself, but I can't easily test all 
possible configuration options and so hadn't run into the reported 
failure.  Thanks Mattia for reporting it.  I fixed the bug in trunk bzr 
116992, by having the glib test mention its dependencies, and am marking 
the bug report as done.

I'm puzzled, though, as to why glib is treated differently from the 
other libraries.  Currently, Emacs uses glib if glib happens to be 
dragged in along with some other library, and avoids glib otherwise. 
Why not just use glib if available?  That would be simpler, no?


This bug report was last modified 11 years and 92 days ago.

Previous Next


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