Bug#772665: produces broken cross compiler packages for mips64el
Waoo, great work.
Now I understand what it is for.
Looong Looong ago, something may make libn32blabla depend on
lib64blabla in control,
so this snap of code exits.
Now we don't have this problem, all libn32blabla depends on
Depends: gcc-4.9-base (= ${gcc:Version}), ${dep:libcbiarch},
${shlibs:Depends}, ${misc:Depends}
No lib64blabla in them, so we should remove these codes.
On Tue, Dec 16, 2014 at 3:34 PM, Helmut Grohne hel...@subdivi.de wrote:
On Wed, Dec 10, 2014 at 09:54:01AM +0100, Matthias Klose wrote:
I can't remember. please ask the Debian mips maintainers. I assume, extending
the expression to entirely remove empty fields should work around this for
now.
I did X-Debbugs-Cc the submission to debian-mips@l.d.o. So now I did
some archeology:
* The affected code was inserted in the gcc-4.4 era.
* It is inserted in SVN revision 4707.
* The commit message closes #594540.
Unfortunately the bug report is rather scarce on details, but it appears
to be talking about library packages. So I went ahead and restricted the
match to lib$biarch. The immediate effect is that it no longer matches
mips64el and thus leaves the Recommends on libc alone. Thus the stage1
becomes installable. I did not notice any excess dependencies.
I could not verify further stages as the stage2 build fails linking the
n32 libc.so, because it insists on linking the 64 one. The latter may be
an error in my build environment.
Nevertheless, I am attaching a patch for what I believe to be the
correct solution.
Helmut
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772665: produces broken cross compiler packages for mips64el
On Wed, Dec 10, 2014 at 09:54:01AM +0100, Matthias Klose wrote: I can't remember. please ask the Debian mips maintainers. I assume, extending the expression to entirely remove empty fields should work around this for now. I did X-Debbugs-Cc the submission to debian-mips@l.d.o. So now I did some archeology: * The affected code was inserted in the gcc-4.4 era. * It is inserted in SVN revision 4707. * The commit message closes #594540. Unfortunately the bug report is rather scarce on details, but it appears to be talking about library packages. So I went ahead and restricted the match to lib$biarch. The immediate effect is that it no longer matches mips64el and thus leaves the Recommends on libc alone. Thus the stage1 becomes installable. I did not notice any excess dependencies. I could not verify further stages as the stage2 build fails linking the n32 libc.so, because it insists on linking the 64 one. The latter may be an error in my build environment. Nevertheless, I am attaching a patch for what I believe to be the correct solution. Helmut diff -u gcc-4.9-4.9.2/debian/rules.defs gcc-4.9-4.9.2/debian/rules.defs --- gcc-4.9-4.9.2/debian/rules.defs +++ gcc-4.9-4.9.2/debian/rules.defs @@ -1759,8 +1759,8 @@ 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,@:) + $(if $(findstring lib64,$(1)),sed -i -r '/^(Dep|Rec|Sug)/s/libn?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/lib64[^$(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
Bug#772665: produces broken cross compiler packages for mips64el
On Wed, 10 Dec 2014 09:54:01 +0100 Matthias Klose d...@debian.org wrote: Control: tags -1 + moreinfo help On 12/09/2014 08:46 PM, Helmut Grohne wrote: 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,@:) I believe that it should be just a workaround in the dark age that control.m4 cannot process some triarch situation. Now we have control.m4 workable, so I believe that we can remove them. It was used by with_deps_on_target_arch_pkgs only, so it is useless now. You can remove these lines. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772665: produces broken cross compiler packages for mips64el
On 12/11/2014 09:35 AM, YunQiang Su wrote: I believe that it should be just a workaround in the dark age that control.m4 cannot process some triarch situation. Now we have control.m4 workable, so I believe that we can remove them. It was used by with_deps_on_target_arch_pkgs only, so it is useless now. You can remove these lines. Please could you verify that, and attach a build log of such a triarch cross build? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772665: produces broken cross compiler packages for mips64el
On Thu, Dec 11, 2014 at 4:57 PM, Matthias Klose d...@debian.org wrote: On 12/11/2014 09:35 AM, YunQiang Su wrote: I believe that it should be just a workaround in the dark age that control.m4 cannot process some triarch situation. Now we have control.m4 workable, so I believe that we can remove them. It was used by with_deps_on_target_arch_pkgs only, so it is useless now. You can remove these lines. Please could you verify that, and attach a build log of such a triarch cross build? In recent modifications: ifneq (,$(filter $(DEB_TARGET_ARCH), mips mipsel mips64 mips64el mipsn32 mipsn32el)) - ifneq ($(with_deps_on_target_arch_pkgs),yes) -define cross_mangle_control + 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)/DEBIA N/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 + endef You removed with_deps_on_target_arch_pkgs condition before it. It was used only when with_deps_on_target_arch_pkgs set, and also now when with_deps_on_target_arch_pkgs set, it is also useless. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772665: produces broken cross compiler packages for mips64el
Control: tags -1 + moreinfo help On 12/09/2014 08:46 PM, Helmut Grohne wrote: 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 I can't remember. please ask the Debian mips maintainers. I assume, extending the expression to entirely remove empty fields should work around this for now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772665: produces broken cross compiler packages for mips64el
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
