16753
Comment:
|
16697
wikify
|
Deletions are marked like this. | Additions are marked like this. |
Line 51: | Line 51: |
For more information, check the [[https://wiki.debian.org/Autoreconf|Debian autoreconf page]] | For more information, check the [[Autoreconf|Debian autoreconf page]] |
Line 95: | Line 95: |
See also https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries | See also [[ToolChain/DSOLinking#Only_link_with_needed_libraries]]. |
Line 219: | Line 219: |
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. | Ubuntu has been using dash as /bin/sh since Ubuntu edgy (released in october 2006). There's a nice page at UbuntuWiki:DashAsBinSh giving some advice. |
This page lists details about build failures that affect several packages (and the "good" way to solve them).
Contents
- 2014-01-21 using dh-autoreconf during the build
- 2013-11-23 FTBFS: QT4_CREATE_MOC_COMMAND Macro invoked with incorrect arguments for macro
- 2013-10-27 checking whether the Boost::Foo library is available... yes configure: error: Could not link against !
- 2013-09-28 fatal error: modplug.h: No such file or directory
- 2013-07-27 ld: undefined reference to symbol 'xyz@@GLIBC_2.2.5'
- 2013-06-09 makeinfo/texinfo complains about @sp missing argument
- 2013-06-01 error: incompatible types when assigning to type '__pyx_t_6cube_c_Vector' from type 'float *'
- 2013-06-31 boost::TIME_UTC: error: expected unqualified-id before numeric constant
- 2013-05-31 makeinfo/texinfo complains about @itemx which does not follow @item
- 2013-02-26 glib2.0: error: 'g_type_init' is deprecated (declared at /usr/include/glib-2.0/gobject/gtype.h:669)
- 2012-03-22 dh_usrlocal: sed: -e expression #1, char 20: extra characters after command
- 2011-09-23 dpkg-source complains about unexpected upstream changes
- 2011-05-04 Libtool complains about file not found on += assignment
- 2011-05-02 Packages failing with GCC 4.6
- 2009-11-18 Packages failing on hurd-i386
- 2009-11-02 Packages failing because binutils-gold/indirect linking
- 2008-05-25 ld: cannot find -ldts
- 2008-04-13 Failures with dpkg-dev 1.14.18
- 2008-01-03 Failures with dash as /bin/sh
- 2007-12-01 Package failing with dpkg-shlibdeps "failure: something" messages
- 2007-09-29 Packages failing to build with GTK+ 2.12 (symbol errors on GTK_TOOLTIPS, gtk_widget_unref and more)
- 2007-09-17 Packages failing to build cause of "called object 'major' is not a function"
- 2007-09-14 Packages failing to build with ecj-gcj due to missing java.lang.object
- 2007-09-12 Packages failing due to undetected libdb
- 2007-08-28 Packages failing because of missing camlp4o
- Build failures caused by directory name
- 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
For more information, check the Debian autoreconf page
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}")
2013-10-27 checking whether the Boost::Foo library is available... yes configure: error: Could not link against !
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:
#include <modplug.h>
by
#include <libmodplug/modplug>
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.
- Add the library in your configure scripts to LIBS, not LDFLAGS.
- Forward the patch upstream.
- 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 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 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.]*')
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.