Problem building gcc-4.4_4.4.4-6 cross-compiler on unstable
While trying to update my patches to allow building of binutils and gcc
with modified prefixes, I found that I could no longer compile a cross
compiler using the manual steps as outlined at
http://wiki.debian.org/EmdebianToolchain with the unstable
gcc-4.4_4.4.4-6 package. I get the following error from dh_shlibdeps
...
cat debian/libgcc1-armel-cross/DEBIAN/shlibs >> debian/shlibs.local
ARCH=armel MAKEFLAGS="CC=something" dh_shlibdeps -plibgcc1-armel-cross
<===== LOOK_HERE
dpkg-shlibdeps: error: couldn't find library libc.so.6 needed by
debian/libgcc1-armel-cross/opt/crosscompiler/gcc-4.4.4/arm/arm-linux-gnueabi/lib/libgcc_s.so.1
(ELF format: 'elf32-littlearm'; RPATH: '').
Note: libraries are not searched in other binary packages that do not
have any shlibs or symbols file.
To help dpkg-shlibdeps find private libraries, you might need to set
LD_LIBRARY_PATH.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/libgcc1-armel-cross.substvars
debian/libgcc1-armel-cross/opt/crosscompiler/gcc-4.4.4/arm/arm-linux-gnueabi/lib/libgcc_s.so.1
returned exit code 2
make[1]: *** [stamps/08-binary-stamp-libgcc] Error 9
make[1]: Leaving directory `/home/jheck/opt-build/gcc-4.4-4.4.4'
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
status 2
This seems to be caused by the fact the LD_LIBRARY_PATH is not getting
defined on the line calling dh_shlibdeps. Note that the variable is
conspicuously missing in the line above marked LOOK_HERE.
I tried compiling without the alternate prefix, and it did indeed work,
but the variable was similarly missing from the dh_shlibdeps line, which
leads me to believe that when compiled under /usr, dh_shlibdeps is
finding some version of libc.so.6 that is satisfying it (hopefully the
crossed one!). When I compile using the alternate prefix, I install the
crossed libc6 to the alternate prefix location by changing the default
crossbase for dpkg-cross, so this is probably why dh_shlibdeps can't
find it in my case without the missing variable.
...
cat debian/libgcc1-armel-cross/DEBIAN/shlibs >> debian/shlibs.local
ARCH=armel MAKEFLAGS="CC=something" dh_shlibdeps -plibgcc1-armel-cross
<===== LOOK_HERE still missing (but somehow works)
sed -i 's/\(lib[^ ]*\) /\1-armel-cross /g'
debian/libgcc1-armel-cross.substvars
dh_gencontrol -plibgcc1-armel-cross -plibgcc1-dbg-armel-cross \
...
I did some debugging and found that the problem stems from the
modifications made to merge the rules.d/binary-*-cross.mk files into
rules.d/binary-*.mk, and the creation of the new makefile variable
'cross_shlibdeps' on line 145 in debian/rules.defs of the
gcc-4.4_4.4.4-6 package. This variable takes the place of the explicit
expansions previously found in the rules.d/binary-*-cross.mk files, but
is defined in the included rules.defs file using a simply expanded (:=)
variable like this
cross_shlibdeps := $(SET_CROSS_LIB_PATH) ARCH=$(DEB_TARGET_ARCH)
MAKEFLAGS="CC=something"
The inclusion of rules.defs is at the top of the debian/rules2 makefile,
and occurs before the definition of the variable 'SET_CROSS_LIB_PATH' on
line 401
SET_CROSS_LIB_PATH =
LD_LIBRARY_PATH=$${LD_LIBRARY_PATH:+$$LD_LIBRARY_PATH:}/$(PF)/$(DEB_TARGET_GNU_TYPE)/lib
Since it is a simply expanded variable, cross_shlibdeps picks up the
null definition for SET_CROSS_LIB_PATH, and then is never updated
again. I was able to fix the problem by changing the definition of
cross_shlibdeps to be a recursively expanded variable.
cross_shlibdeps = $(SET_CROSS_LIB_PATH) ARCH=$(DEB_TARGET_ARCH)
MAKEFLAGS="CC=something"
Indeed, once I do this, the variable reappears in the dh_shlibdeps line
...
cat debian/libgcc1-armel-cross/DEBIAN/shlibs >> debian/shlibs.local
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}/opt/crosscompiler/gcc-4.4.4/arm/arm-linux-gnueabi/lib
ARCH=armel MAKEFLAGS="CC=something" dh_shlibdeps -plibgcc1-armel-cross
sed -i 's/\(lib[^ ]*\) /\1-armel-cross /g'
debian/libgcc1-armel-cross.substvars
dh_gencontrol -plibgcc1-armel-cross -plibgcc1-dbg-armel-cross \
...
While this is not causing problems when compiled under /usr, I do think
this is a bug, since the LD_LIBRARY_PATH that is intended to be expanded
before calling dh_shlibdeps is not there. It was needed in the past,
and I'm not sure exactly why it is working now, but I think it would be
safest to fix this so that it works equivalently to how it was intended
with the proper expansion of the LD_LIBRARY_PATH variable on the
dh_shlibdeps line.
Here is a patch to the debian/rules.defs file for gcc-4.4_4.4.4-6 to
change it from a simply expanded variable to a recursively expanded variable
jheck@squeeze2:~/opt-build/gcc-4.4-4.4.4/debian$ diff rules.defs.orig
rules.defs145c145
< cross_shlibdeps := $(SET_CROSS_LIB_PATH) ARCH=$(DEB_TARGET_ARCH)
MAKEFLAGS="CC=something"
---
> cross_shlibdeps = $(SET_CROSS_LIB_PATH) ARCH=$(DEB_TARGET_ARCH)
MAKEFLAGS="CC=something"
Can someone help me report this bug, but I'm still uncertain as to how
exactly to file such a bug (sorry, I haven't done too much bug reporting..)
Incidentally, for the gcc-4.4_4.4.4-6 package, my prefix modification
has become even more simple after the changes from 4.4.4-5 to 4.4.4-6.
For the gcc-4.4 package, it is now down to a single very simple change
to the debian/rules2 file as follows.
jheck@squeeze2:~/opt-build/gcc-4.4-4.4.4/debian$ diff rules2.orig rules2
503,504c503,505
< # It's "usr" for gcc releases
< ifeq ($(PKGSOURCE),gcc-snapshot)
---
> # It's "usr" for gcc releases, so use this if not explicitly set
> ifneq ($(PF),)
> else ifeq ($(PKGSOURCE),gcc-snapshot)
I also have a diff file for binutils, for the prefix modification based
on the current 2.20.51.20100617-1 version, which is more extensive. I
can post that if that is the version that will be migrating to
unstable. Is there a timetable for that migration?
-Jim Heck
Reply to: