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

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

This is due to [http://lists.debian.org/debian-devel-announce/2011/09/msg00001.html changes introduced by dpkg 1.16.1].

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 don't linking to it; libqt*, but only linking to kdecore. Another interesting problem is that some problem links there C++ object files using gcc instead of g++, but the g++ symbols gets 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.