Package: src:gcc-4.9
Version: 4.9.2-5
User: helm...@debian.org
Usertags: rebootstrap
When building a cross compiler for mips64el (and possibly other mips
architectures), some binary packages are broken.
$ dpkg-deb -I ./libn32gcc-4.9-dev-mips64el-cross_4.9.2-5_all.deb
new debian package, version 2.0.
size 86302 bytes: control archive=850 bytes.
503 bytes, 14 lines control
854 bytes, 9 lines md5sums
Package: libn32gcc-4.9-dev-mips64el-cross
Source: gcc-4.9
Version: 4.9.2-5
Architecture: all
Maintainer: Debian GCC Maintainers <debian-...@lists.debian.org>
Installed-Size: 2484
Depends: gcc-4.9-base (= 4.9.2-5)
Recommends:
Section: libdevel
Priority: optional
Homepage: http://gcc.gnu.org/
Description: GCC support library (n32 development files)
This package contains the headers and static library files necessary for
building C programs which use libgcc, libgomp, libquadmath, libssp or libitm.
$
Please pay attention to the value of Recommends. It is an empty field,
but the field is still there. This makes e.g. apt-get update choke:
| Reading package lists...
| E: Problem parsing dependency Recommends
| E: Error occurred while processing libn32gcc-4.9-dev-mips64el-cross
(NewVersion2)
| E: Problem with MergeList /var/lib/apt/lists/...
| E: The package lists or status file could not be parsed or opened.
One wonders how an empty Recommends field can end up in the control
file, when dpkg-gencontrol explicitly discards empty fields. In fact,
the field is not empty after the dpkg-gencontrol invocation. Instead it
contains:
| Recommends: libc6-dev-mips64el-cross (>= 2.13-5)
A bit later the following command is executed during build:
| sed -i -r '/^(Dep|Rec|Sug)/s/[a-z0-9-]+64[^,]+(,
*|$)//g;/^(Dep|Rec|Sug)/s/libgcc1-mips64el-cross/libn32gcc1-mips64el-cross/;/^(Dep|Rec|Sug)/s/
*, *$//' debian/libn32gcc-4.9-dev-mips64el-cross/DEBIAN/control
The first command in the sed expression discards the libc dependency.
It comes from debian/rules.defs:
| ifneq (,$(filter $(DEB_TARGET_ARCH), mips mipsel mips64 mips64el mipsn32
mipsn32el))
| define cross_mangle_control
| $(if $(findstring lib64,$(1)),sed -i -r
'/^(Dep|Rec|Sug)/s/[a-z0-9-]+32[^$(COMMA)]+($(COMMA)
*|$$)//g;/^(Dep|Rec|Sug)/s/$(p_lgcc)/$(p_l64gcc)/;/^(Dep|Rec|Sug)/s/ *$(COMMA)
*$$//' debian/$(1)/DEBIAN/control,@:)
| $(if $(findstring libn32,$(1)),sed -i -r
'/^(Dep|Rec|Sug)/s/[a-z0-9-]+64[^$(COMMA)]+($(COMMA)
*|$$)//g;/^(Dep|Rec|Sug)/s/$(p_lgcc)/$(p_ln32gcc)/;/^(Dep|Rec|Sug)/s/ *$(COMMA)
*$$//' debian/$(1)/DEBIAN/control,@:)
| endef
| else
| define cross_mangle_control
| endef
| endif
I would like to provide a fix for this, but I fail to understand what
this cross_mangle_control is supposed to achieve. The last time this was
touched was #758408, where they caused other kind of havoc. An obvious
idea is to replace "[a-z0-9-]+" with "lib", but without understanding
why this was added initially, I cannot tell whether the prospective fix
breaks the original use case.
Fact is that currently, the cross compilers generated for mips64el are
broken.
Helmut
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
