As of me writing this post, there are about 428 packages that have failed to build from source (FTBFS)]. We’re doing a FTBFS jam this Wednesday (29 June, 2011). If you’re interested in helping out, drop by in #ubuntu-motu) and just generally say that you want to help fix FTBFS and someone will be able to guide you. We have a list of packages that are potential targets to be fixed.
While we won’t try to fix everything, we’ll be focusing on specifc failures, the ones caused by toolchain changes. Ubuntu is changing the way it handles shared library linking. Similar changes are also happening in Debian.
Before I get into spare details of the reason for these build failures, I’d like to emphasise that the failures that we’re targetting to fix are quite easy and just needs some tinkering with make files. I recently fixed a build failure in the redis package. Take a look at the build log of the failure, the patch that fixed it, and the build log after the fix.
Cause of the failure
For more information on fixing these failures, please see the Ubuntu wiki page and the Debian wiki page.
Previously, the linker (ld) would allow indirect linking of shared library symbols. For example, if you had a function spin in the library libwheel, and the library libcar used libwheel, then a program that used libcar would have the ability to call spin even though it never directly used libwheel. This kind of indirect linking leads to fragile code; when the dependency chain of a shared library changes, it can break the program that used it.
ld now runs with the --no-copy-dt-needed-entries option enabled by default. This option is also sometimes called --no-add-needed. This means that, in the example above, the spin function would only be available when libwheel was directly linked by adding -lwheel to the command-line compiler flags, and not available indirectly through libcar. Also, ld runs with the --as-needed option enabled by default. This means that, in the example above, if no symbols from libwheel were needed by racetrack, then libwheel would not be linked even if it was explicitly included in the command-line compiler flags.
The solution to a build error caused by indirect linking, is to directly link all needed libraries in the compiler flags on the command-line. For example, if you were previously linking with -lcar -ltruck, you would now need to explicitly add -lwheel. For example:
gcc -Wall racetrack.c -lcar -ltruck -lwheel -o racetrack The --as-needed option also makes the linker sensitive to the ordering of libraries on the command-line. You may need to move some libraries later in the command-line, so they come after other libraries or files that require symbols from them. For example, the following link line is wrong, and needs to be changed so that libraries come after objects that use them:
gcc -Wall -lwheel -lcar -ltruck -o racetrack racetrack.c When problems result from the --no-copy-dt-needed-entries option, the linker will always give you a hint at the right fix in the error message, for example ‘try adding it to the linker command line’.
Leave a Reply