Differences between revisions 21 and 22
Revision 21 as of 2007-05-06 20:26:14
Size: 9159
Editor: NeilWilliams
Comment: describe a common shlib error
Revision 22 as of 2007-05-06 20:38:42
Size: 9393
Editor: NeilWilliams
Comment:
Deletions are marked like this. Additions are marked like this.
Line 132: Line 132:
Then change the {{{dh_shlibdeps}}} rule in {{{debian/rules}}} to specify to look for the dependency information within the current build tree using {{{-L}}} and {{{-l}}}:
{{{
dh_shlibdeps -L libacl1 -l ./debian/libacl1/lib/
}}}

Emdebian Developer Guide

This is intended to provide tips and status information on the emdebianisation of Debian packages, problems encountered, solutions found and details of problematic packages. In due course, the advice here will be distilled into a dedicated Developer Guide and into the currently unformed Emdebian Policy documentation.

Anything that expands or clarifies issues in the emdebian-tools manpages can also be added here.

See also EmdebianQuickStart and ["Embedded_Debian"].

Cache Files

Packages consisting of compiled C code and using the autotools can support a cache file of values to help the ./configure script to identify settings for the target that differ from the architecture performing the build. Cache files can also be used to provide the answer when letting ./configure calculate the result would end in failure. Typically, this is due to ./configure trying to compile a test program on the build architecture using the target compiler - resulting in trying to run an arm binary on, say, amd64. To prevent such disasters, the value that the test program is trying to calculate can be provided in a cache file and autotools will skip the test program.

Currently, values for these cache files need to be elucidated the hard way: Let the build fail, work out where it failed, find the cache variable that would prevent the failing code from being run and then look up the value for that variable in the build logs of the native build in Debian.

dpkg-gencontrol: error

Packages that use CDBS handle emlocale automatically. Packages that use debhelper need minor tweaks to ensure that the new packages created for the translation files get populated correctly. The problem comes with something like a rootfs where packages use the dpkg commands directly. To create and populate the translation packages, manual editing of debian/rules is necessary.

You need to add a clean: rule and a loop to build:

e.g. for diff (source package name diffutils), the loop for the build target consists of:

srcpkg=diffutils \
POFILES=`cd po && ls *.po | sed -e 's/\.po$$//'` ; \
for po in $$POFILES; do \
        TMPPO=`basename $$po | cut -f1 -d.` ; \
        TMPPKG=`echo $$TMPPO | tr '_@A-Z' '-+a-z'` ; \
        install -d debian/$$srcpkg-locale-$$TMPPKG/DEBIAN ; \
        install -d debian/$$srcpkg-locale-$$TMPPKG/usr/share/locale/$$TMPPO/LC_MESSAGES/ ; \
        install po/$$TMPPO.gmo debian/$$srcpkg-locale-$$TMPPKG/usr/share/locale/$$TMPPO/LC_MESSAGES/$$srcpkg.mo ; \
        dpkg-gencontrol -p$$srcpkg-locale-$$TMPPKG -Pdebian/$$srcpkg-locale-$$TMPPKG ; \
        dpkg --build debian/$$srcpkg-locale-$$TMPPKG .. ; \
done

Take care : your web browser could have added a line break in the long install line in the loop. The installation of po/bar.gmo into debian/foo/usr/share/locale/bar/LC_MESSAGES is a single line in debian/rules. Try reducing the font size or zoom level in your browser to get the correct line wrapping.

Remember to set the SOURCE package name in srcpkg and be very careful to retain all the double dollars.

Now remove the locale files from the parent package:

${RM} -r debian/tmp/usr/share/locale/

(Watch for packages that use foo-common or foo-data instead of tmp and update as appropriate.)

And finally, add a clean target:

${RM} -r debian/diffutils-locale-*

(Note here that $srcpkg is not available, you can move the variable elsewhere or just specify the source package name explicitly. The variable is only really to make it easy to migrate the loop between packages.)

Thanks to Julian Gilbey for the idea and fixes.

Problematic packages

  1. gnupg /usr/arm-linux-gnu/include/sys/types.h:72: error: two or more data types in declaration specifiers

  2. perl-base Tries to run cross-built miniperlmain and possibly other generated binaries during make.

  3. e2fsprogs Needs cross-compiler support - upstream hardcodes CC instead of ${CC}

  4. findutils Source contains the .texi files that we don't need but the clean process deletes the upstream files and expects them to be rebuilt. The make system then complains that: "WARNING: ../gnulib/lib/regex.h is newer than regexprops.texi but regexprops.texi cannot be rebuilt because we are cross-compiling. Continuing anyway." Except that it cannot continue because regexprops.texi is referenced later in the same doc/ directory build! (This is a bug upstream - reporting ...) This bug has been fixed upstream.

  5. dhcp3 dpatch is no longer idempotent when cross-building. fix_64-bit fails to reverse. As that is a 227kb patch (!) it's not a simple fix [pun intended]. Like findutils above, the temporary solution is to check in the emdebian-rules.patch file to SVN, remove the entire contents of svn/d/dhcp3/trunk/* re-run emsource dhcp3 and then rebuild. Horrid. You can omit the commit and download if you unpack the debian source manually and then apply the emdebian patch files manually.

  6. pam Relocations in generic ELF. dynamic/pam_item.o: could not read symbols: File in wrong format

  7. gcc-4.1 - strange, but yes Emdebian does appear to need to cross-build gcc using a cross-built toolchain and if that confuses you, it also appears to confuse gcc. See the section on gcc.

gcc-4.1

gcc-4.1 is needed to build libgcc1. Despite emdebuild passing -a arm to dpkg-buildpackage, gcc appears to get confused by the presence of the cross-building toolchain.

The build halts after outputting:

checking build system type... arm-unknown-linux-gnu
checking host system type... arm-unknown-linux-gnu
checking for arm-linux-gnu-ar... arm-linux-gnu-ar
checking for arm-linux-gnu-ranlib... arm-linux-gnu-ranlib
checking for arm-linux-gnu-gcc... arm-linux-gnu-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.

Except that we are using --host:

dpkg-buildpackage: source package is gcc-4.1
dpkg-buildpackage: source version is 4.1.2-5em1
dpkg-buildpackage: source changed by Neil Williams <codehelp@debian.org>
dpkg-architecture: warning: Specified GNU system type arm-linux-gnu does not match gcc system type x86_64-linux-gnu.
dpkg-architecture: warning: Specified GNU system type arm-linux-gnu does not match gcc system type x86_64-linux-gnu.
dpkg-buildpackage: host architecture arm

Now maybe I'm just really confused already but the toolchain consists of (amongst other packages)

gcc-4.1-arm-linux-gnu_4.1.1-21_amd64.deb
libgcc1-arm-cross_4.1.1-21_all.deb

When what the Emdebian target repository needs is:

libgcc1_4.1.1-21_arm.deb

gcc-4.1_4.1.1-21_arm.deb would be built as well but the [:EmdebianRootfs: rootfs] only needs libgcc1.

(See the [http://www.emdebian.org/packages/search.php?package=cdebconf&arch=arm&distro=unstable cdebconf dependencies] as an example.

:-(

dh_shlibdeps errors

dh_shlibdeps
dpkg: /usr/arm-linux-gnu/lib/libacl.so.1 not found.
dpkg-shlibdeps: failure: dpkg --search gave error exit status 1
dh_shlibdeps: command returned error code 256

Check for the existence of the file within the build:

$ find . -name libacl.so.1
./debian/libacl1/lib/libacl.so.1
./libacl/.libs/libacl.so.1

and re-run dh_shlibdeps with the -l option:

$ dh_shlibdeps -l ./debian/libacl1/lib/
dpkg-shlibdeps.orig: warning: could not find any packages for libattr.so.1

Note that this example comes from libacl1 but the reference is to libattr - this gives you a clue that you need to use apt-cross - this is an [:EmdebianCrossPackages: Build-Cross-Depends] package.

$ sudo apt-cross -i libattr1

Then change the dh_shlibdeps rule in debian/rules to specify to look for the dependency information within the current build tree using -L and -l:

dh_shlibdeps -L libacl1 -l ./debian/libacl1/lib/

Incomplete build logs

It would be useful to have a place for incomplete build-logs - failure logs - but this service is not currently available on the emdebian server.

apt-cross

Until an equivalent to pbuilder is available for cross-building, the build host will need to install cross versions of the -dev packages required by the package being built. apt-cross -v -i libfoo-dev.

Status Table

A [http://buildd.emdebian.org/svn/file/current/emdebian/trunk/logs/buildstatus buildstatus] script is available in SVN which will update your emdebian working directory and then count the number of packages where work has started, show how many patches are present for each and whether a build log was found. Build logs are present even if the build failed so this is only indicative of whether a build has been attempted. The final arbiter of whether a build was successful is the presence of a build log in SVN and the presence of a package in the Emdebian target repository. Unfortunately, I haven't yet found a quick way of checking SVN for build logs - using svn list took too long.


CategoryEmdebian