Bug#772665: produces broken cross compiler packages for mips64el

Package: src:gcc-4.9
Version: 4.9.2-5
User: [email protected]
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 <[email protected]>
 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