|Deletions are marked like this.||Additions are marked like this.|
|Line 2:||Line 2:|
== 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 [[https://mail.gnome.org/archives/commits-list/2012-November/msg07809.html|this upstream commit]] (several other examples available if you search):
This page lists details about build failures that affect several packages (and the "good" way to solve them).
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 126.96.36.199 (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
441660 tex4ht: FTBFS: The type java.lang.Object cannot be resolved
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
441763 (libdb4.2): “libdb-4.2.so must link against libpthread”
441870 (libdb4.3-dev): “libdb.so must link against libpthread”.
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.]*')
version:=$(shell dpkg-parsechangelog | grep Version: | cut -d ' ' -f 2 | cut -d '-' -f 1) version_major:=$(shell echo $(version) | cut -d '.' -f 1)
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.