This page lists details about build failures that affect several packages (and the "good" way to solve them).

Contents

  1. 2014-01-21 using dh-autoreconf during the build
  2. 2013-11-23 FTBFS: QT4_CREATE_MOC_COMMAND Macro invoked with incorrect arguments for macro
  3. 2013-10-27 checking whether the Boost::Foo library is available... yes configure: error: Could not link against !
  4. 2013-09-28 fatal error: modplug.h: No such file or directory
  5. 2013-07-27 ld: undefined reference to symbol 'xyz@@GLIBC_2.2.5'
  6. 2013-06-09 makeinfo/texinfo complains about @sp missing argument
  7. 2013-06-01 error: incompatible types when assigning to type '__pyx_t_6cube_c_Vector' from type 'float *'
  8. 2013-06-31 boost::TIME_UTC: error: expected unqualified-id before numeric constant
  9. 2013-05-31 makeinfo/texinfo complains about @itemx which does not follow @item
  10. 2013-02-26 glib2.0: error: 'g_type_init' is deprecated (declared at /usr/include/glib-2.0/gobject/gtype.h:669)
  11. 2012-03-22 dh_usrlocal: sed: -e expression #1, char 20: extra characters after command
  12. 2011-09-23 dpkg-source complains about unexpected upstream changes
  13. 2011-05-04 Libtool complains about file not found on += assignment
  14. 2011-05-02 Packages failing with GCC 4.6
  15. 2009-11-18 Packages failing on hurd-i386
  16. 2009-11-02 Packages failing because binutils-gold/indirect linking
  17. 2008-05-25 ld: cannot find -ldts
  18. 2008-04-13 Failures with dpkg-dev 1.14.18
  19. 2008-01-03 Failures with dash as /bin/sh
  20. 2007-12-01 Package failing with dpkg-shlibdeps "failure: something" messages
  21. 2007-09-29 Packages failing to build with GTK+ 2.12 (symbol errors on GTK_TOOLTIPS, gtk_widget_unref and more)
  22. 2007-09-17 Packages failing to build cause of "called object 'major' is not a function"
  23. 2007-09-14 Packages failing to build with ecj-gcj due to missing java.lang.object
  24. 2007-09-12 Packages failing due to undetected libdb
  25. 2007-08-28 Packages failing because of missing camlp4o
  26. Build failures caused by directory name
  27. Network access

2014-01-21 using dh-autoreconf during the build

The easiest way is a dependency on dh-autoreconf and using that during the package build. If the package is already using the autools-dev package, make sure that the config.guess and config.sub files are also updated by dh-autoreconf; for very few cases you need to use both tools (see #698765).

To check that the libtool change was picked up, grep the regenerated files for the powerpc64le string. To check that the config.* changes were picked up, grep for the aarch64-linux-gnu string.

For new debhelper based packages:

%:
        dh $@ --with autoreconf

For old debhelper based packages

configure-stamp:
        dh_autoreconf
        ./configure ...

clean:
        dh_autoreconf_clean
        dh_clean

For cdbs based packages:

include /usr/share/cdbs/1/rules/autoreconf.mk

If the package isn't ready to use the recent autotools versions, then you can force dh-autoreconf to use older ones:

export AUTOMAKE = automake-1.11
export ACLOCAL = aclocal-1.11

If the regeneration is failing with missing autoconf macros, search the archive for the macros (mostly provided in /usr/share/aclocal), and build-depend on these packages.

If the regeneration is still failing, talk to the upstream to update to newer autotools and backport the patches.

If anything else fails, patch the generated files directly (should be avoided). This includes the config.guess and config.sub files, and the libtool.m4 and aclocal.m4 files and depending configure files.

Bug reports to introduce dh-autoreconf during the build are tracked with usertags

User: debian-devel@lists.debian.org
Usertags: autoreconf

2013-11-23 FTBFS: QT4_CREATE_MOC_COMMAND Macro invoked with incorrect arguments for macro

The number of arguments in QT4_CREATE_MOC_COMMAND seems to have changed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9ce60ff509c4ff27fe861fc5b2080f50897a68c4

Suggested solution (not sure if this is the "good" way to solve this, please correct it if you have a deeper insight):
-    QT4_CREATE_MOC_COMMAND(${infile} ${outfile} "${moc_flags}" "${moc_options}")
+    QT4_CREATE_MOC_COMMAND(${infile} ${outfile} "${moc_flags}" "${moc_options}" "${moc_target}")

Boost is now multiarched, and it's libraries are in standard multiarch locations. Unfortunately autoconf archive based m4 macros for boost detection fail by default thus the following option needs to be passed to the configure scripts

include /usr/share/dpkg/default.mk
dh_auto_configure -- --with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH)    

2013-09-28 fatal error: modplug.h: No such file or directory

A recent change to libmodplug removed the -Ilibmodplug that was configured for package using pkg-config to setup the build environement. You will have to replace occurence of:

by

2013-07-27 ld: undefined reference to symbol 'xyz@@GLIBC_2.2.5'

If your package fails to build from source with the ld: undefined reference to symbol error, it usually indicates that libraries that are needed to build the package are not linked in.

  1. Add the library in your configure scripts to LIBS, not LDFLAGS.
  2. Forward the patch upstream.
  3. Do not use DEB_LDFLAGS_MAINT_APPEND to add the missing library in debian/rules. This works in Debian if you pass e.g. -lm before -Wl, --as-needed but will fail in derivatives like Ubuntu when --as-needed is already called as the standard implementation.

See also https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries

and the autoconf manual (LDFLAGS and LIBS)

https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Preset-Output-Variables.html

2013-06-09 makeinfo/texinfo complains about @sp missing argument

Starting with texinfo 5.0 some incompatible changes wrt 4.13 and below have been introduced. Notably the above warning has turned into an error in 5.0 and above.

As the documentation of texinfo states, after @sp must follow the number of blank lines.

A way to fix this is:

-@sp
+@sp 1

2013-06-01 error: incompatible types when assigning to type '__pyx_t_6cube_c_Vector' from type 'float *'

Newer gcc complains about missing type cast. The "__pyx_" prefix indicates that the code is generated by Cython from a '.py' or a '.pyx' file. Type cast is done like this:

v0 = cython.cast(cython.p_float, get_faces(i)[face].normal)  # .py files
v0 = <float*>get_faces(i)[face].normal  # .pyx files

2013-06-31 boost::TIME_UTC: error: expected unqualified-id before numeric constant

TIME_UTC is a C11 macro that colides with boost::TIME_UTC. In Boost 1.50, this constant was renamed to TIME_UTC_. To fix it use the new symbol name:

-boost::xtime_get(&wakeup_time, boost::TIME_UTC);
+boost::xtime_get(&wakeup_time, boost::TIME_UTC_);

2013-05-31 makeinfo/texinfo complains about @itemx which does not follow @item

Starting with texinfo 5.0 some incompatible changes wrt 4.13 and below have been introduced. Notably the above warning has turned into an error in 5.0 and above.

As the documentation of texinfo (info texinfo, chapter 11.4.3) states: Use '@item' for the first entry, and '@itemx' for all subsequent entries; '@itemx' must always follow an '@item' command, with no blank line intervening.

That means the simples way to fix this is to convert the first occurence of an itemx into item. Typical patch from the lilypond package:

@@ -1001,20 +1001,20 @@
 ...
 @end example

-@itemx --skip-lily-check
+@item --skip-lily-check
 Do not fail if no lilypond output is found.  It is used for LilyPond
 Info documentation without images.

-@itemx --skip-png-check
+@item --skip-png-check
 Do not fail if no PNG images are found for EPS files.  It is used for
 LilyPond Info documentation without images.
...

2013-02-26 glib2.0: error: 'g_type_init' is deprecated (declared at /usr/include/glib-2.0/gobject/gtype.h:669)

Starting with 2.35, glib2.0 deprecated the g_type_init function. You don't need to call it at all. If you're building with -Werror=deprecated-declarations then you'll get a build failure if you do call it. You can either remove the call completely if you don't care about building on olrder glib versions or, if you do, do something like this upstream commit (several other examples available if you search):

#if !GLIB_CHECK_VERSION(2,35,0)
g_type_init()
#endif

2012-03-22 dh_usrlocal: sed: -e expression #1, char 20: extra characters after command

Introduced by debhelper 9.20120311 (assumed to be the fix for #660794). Niko agrees and has reassigned #665263 to debhelper. Fixed in 9.20120322

2011-09-23 dpkg-source complains about unexpected upstream changes

This is due to changes introduced by dpkg 1.16.1, in particular: "dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail if it detects upstream changes which are not managed by a quilt patch."

Many of the failures with dpkg 1.16.1 will no longer happen with dpkg 1.16.1.1 (bugfix here), but the presence of a debian/patches/debian-changes-<ver> file is still a sign of a problem in your workflow. Usually it means that the clean rule does not bring the build directory to its initial state and that some cruft is left-over. If that's the case you should fix this (and delete the automatic patch).

If the automatic patch contains desired changes, then you should really rename it and document it properly with a DEP-3 header. If it contains desired changes that are not managed with quilt but with your VCS, then you should put "single-debian-patch" in debian/source/local-options.

2011-05-04 Libtool complains about file not found on += assignment

This is a bashism, the problem stems from an out-of-sync setting for the SHELL variable. The libtool script in the build directory is generated at build time by configure, and it will use bashisms if the shell detected is bash, but then the Makefiles might be calling the script explicitly with /bin/sh. The solution is to search for SHELL variables in Makefile.in and assign to them @SHELL@.

2011-05-02 Packages failing with GCC 4.6

With g++ 4.6, the type size_t is no longer defined by including things like STL. The correct fix is to explicitly include either <stddef.h> (for ::size_t) or <cstddef> (for std::size_t).

2009-11-18 Packages failing on hurd-i386

Two lists of porting guidelines are available on http://www.debian.org/ports/hurd/hurd-devel-debian and http://www.gnu.org/software/hurd/hurd/porting/guidelines.html . A porter box is available as strauss.debian.net

2009-11-02 Packages failing because binutils-gold/indirect linking

Some packages fail to build with binutils-gold due to undefined reference. This is in most cases the problem that your executable links against a library A which links against library B, but your executable needs symbols in library B. This is problematic in the situation where library A removes its dependency to library B. The next time the executable gets rebuild it will break and cannot be linked.

This doesn't affect the created executable as it will still have entries in DT_NEEDED for both library A and library B in the case of an successful build. It isn't known which will be the preferred linker in the future or if the behavior will be changed in GNU ld or GNU gold. As the debian buildd's still use the original GNU ld the bugs aren't release critical and it is sufficient to inform upstream.

All packages can be fixed by adding the needed library which provides the symbols to the linker call. In some cases the pkg-config file of library A could be broken as it requires library B for the build. This could be the case if the executable doesn't use library B directly in its source code, but library A inserts the symbols of library B using defines or other similar mechanisms inside their header files to executable, but hasn't the correct Requires statement inside the .pc file of library B.

A common problem seems to be calls to XOpenDisplay without directly linking to -lX11, but to a library like Xtst. Similar is to use glib2.0, but only linking to gtk2.0: using libm, but not linking to it; libqt*, but only linking to kdecore. Another interesting problem is that some program links its C++ object files using gcc instead of g++, but the g++ symbols get resolved by another C++ library they link to.

This problem can be seen when either giving parameter --no-add-needed to the linker (-Wl,--no-add-needed when linking either through gcc or g++) or installing binutils-gold_2.20-1.

A discussion about that issue can be found at http://lists.debian.org/debian-devel/2009/11/msg00099.html

2008-05-25 ld: cannot find -ldts

This happens compiling multimedia packages with gcc 4.3. To avoid it, add libdts-dev to the Build-Depends in debian/control. This package contains the headers and static libraries used to build applications that use libdts (-ldts).

2008-04-13 Failures with dpkg-dev 1.14.18

dpkg now sets default values for CFLAGS, CPPFLAGS, etc (see dpkg-buildpackage(1)). This can break some build scripts that don't deal with those variables nicely.

2008-01-03 Failures with dash as /bin/sh

Ubuntu has been using dash as /bin/sh since Ubuntu edgy (released in october 2006). There's a nice page at https://wiki.ubuntu.com/DashAsBinSh giving some advice.

2007-12-01 Package failing with dpkg-shlibdeps "failure: something" messages

Check the dpkg-shlibdeps man page in dpkg-dev 1.14.12, it contains explanations of those new failures and suggestion on how to fix them.

2007-09-29 Packages failing to build with GTK+ 2.12 (symbol errors on GTK_TOOLTIPS, gtk_widget_unref and more)

GTK+ 2.12 deprecated a bunch of API and packages that define GTK_DISABLE_DEPRECATED now fail to build. Easy solution is to remove GTK_DISABLE_DEPRECATED from CFLAGS; better solution is to port to newer API (upstream may already have done it).

2007-09-17 Packages failing to build cause of "called object 'major' is not a function"

nfs-utils fixed it this way (#442122, from 09-define-major-minor.patch):

#ifndef major
# define major(dev) gnu_dev_major (dev)
#endif
#ifndef minor
# define minor(dev) gnu_dev_minor (dev)
#endif
[..]

2007-09-14 Packages failing to build with ecj-gcj due to missing java.lang.object

Somewhere between 3.3.0+0728-1 and 3.3.0+0728-4 "ecj" dropped its dependency on gij which was used to build it. Packages should build fine with 3.3.0+0728-5 upwards. -- KapilHariParanjape

2007-09-12 Packages failing due to undetected libdb

Please block those FTBFSes with the appropriate libdb bug. -- CyrilBrulebois

2007-08-28 Packages failing because of missing camlp4o

Quite some packages fail because camlp4 has been moved from ocaml-nox's Build-Depends to Recommends. The Ocaml team has tightened their Build-Depends and wants the Packages B-D on caml4p directly:

09:35 <abi> as of the recent rebuild sid/x86 about ~10 packages FTBFS because of missing camlp4o, do the packages have to Build-Depend on camlp4 or would it make more sense to move it from the Recommends to Depends in ocaml-nox

09:35 <abi> i just wonder if i should file the bug for the packages or ocaml-nox

09:36 <smimou> well I think that we should tighten our build-deps instead

09:37 <smimou> we have already started doing this

09:37 <abi> ok, so im going to file the bugs against the packages rather than ocaml-nox?

09:37 <smimou> yes, please

09:38 <smimou> camlp4 is quite a big package so I'd rather avoid ocaml depending on it

Build failures caused by directory name

The buildd's version of sbuild, apt-get source, pbuilder all name the directory the package is unpackad in <sourcepackagename>-<upstream version> but the version of sbuild lucas uses names them <sourcepackagename>-<complete version>. Some packages unwisely rely on the directory name to extract version information for use in the rules. This very often causes files to be misnamed or missing which causes strange failures later (often in dpkg-shlibdeps).

A quick glance at debian/rules for such issues is generally a good idea when a build seems to work elsewhere but fails on lucas's rebuild pool.

Theese issues are usually easy to fix once identified, for example one may replace

version=$(shell expr `pwd` : '.*-\([0-9.]*\)')
version_major=$(shell expr `pwd` : '.*-\([0-9]*\).[0-9.]*')

with

version:=$(shell dpkg-parsechangelog | grep Version: | cut -d ' ' -f 2 | cut -d '-' -f 1)
version_major:=$(shell echo $(version) | cut -d '.' -f 1)

Network access

Network should not be considered available at build time. Difference of network availability can explain why a package builds fine on your computer but not on a buildd or during QA mass-rebuilds. At the bottom of some build logs, an iptables log is available to help you figure out if this was the cause of the build failure. However, the network accesses might have been caused by another package building concurrently on the same node, so use this information with care.