Control: reopen -1 Whilst bootstrapping gdbm no longer requires bootstrapping dietlibc, this does not change whether dietlibc FTCBFS, which is what this bug is about. It is obviously less important now though.
Regards, James On Sat, Feb 10, 2018 at 03:12:06PM +0000, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the src:dietlibc package: > > #889080: dietlibc FTCBFS: dietlibc is difficult > > It has been closed by Gianfranco Costamagna <locutusofb...@debian.org>. > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Gianfranco Costamagna > <locutusofb...@debian.org> by > replying to this email. > > > -- > 889080: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889080 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > Date: Sat, 10 Feb 2018 15:08:44 +0000 > From: Gianfranco Costamagna <locutusofb...@debian.org> > To: 889080-cl...@bugs.debian.org > Subject: Bug#889080: fixed in gdbm 1.14.1-3 > > Source: gdbm > Source-Version: 1.14.1-3 > > We believe that the bug you reported is fixed in the latest version of > gdbm, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 889...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Gianfranco Costamagna <locutusofb...@debian.org> (supplier of updated gdbm > package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > Format: 1.8 > Date: Sat, 10 Feb 2018 13:45:31 +0100 > Source: gdbm > Binary: libgdbm5 gdbm-l10n libgdbm-dev gdbmtool libgdbm-compat4 > libgdbm-compat-dev > Architecture: source > Version: 1.14.1-3 > Distribution: unstable > Urgency: medium > Maintainer: Dmitry Bogatov <kact...@gnu.org> > Changed-By: Gianfranco Costamagna <locutusofb...@debian.org> > Description: > gdbm-l10n - GNU dbm database routines (translation files) > gdbmtool - GNU dbm database routines (command line tools) > libgdbm-compat-dev - GNU dbm database routines (legacy support development > files) > libgdbm-compat4 - GNU dbm database routines (legacy support runtime version) > libgdbm-dev - GNU dbm database routines (development files) > libgdbm5 - GNU dbm database routines (runtime version) > Closes: 889057 889080 889107 889474 > Changes: > gdbm (1.14.1-3) unstable; urgency=medium > . > [ Helmut Grohne ] > * Add pkg.gdbm.nodietlibc build profile. (Closes: #889474) > . > [ Gianfranco Costamagna ] > * Team upload > * Fixup typo in breaks, leading to upgrade failures (Closes: #889107) > Thanks <anbe> for the useful bug report! > * Remove ia64 from dietlibc (Closes: #889057) > * Disable for now dietlibc build, it makes bootstrap really problematic, > and needs some extra work (Closes: #889080). > Checksums-Sha1: > b79919ae55d8364814aaaa3dcd7b7763232adfef 2122 gdbm_1.14.1-3.dsc > d77215e7feae11c00e30a82af88094000c9fedc0 25932 gdbm_1.14.1-3.debian.tar.xz > 7d73427cf0e16843d461e5725eaf398914170bd4 6742 gdbm_1.14.1-3_source.buildinfo > Checksums-Sha256: > f74a56e78dbc6308118e272a53bbb5acc5ec1c527510a41c6c9e9ec5f8361083 2122 > gdbm_1.14.1-3.dsc > 5d499c3cc64c85636f5cf3cdba6a2dea17d86a6527b23ebf374e29603f79db49 25932 > gdbm_1.14.1-3.debian.tar.xz > 0a0008a3b15adc6fda4074bceb263dc20dfbe97fbd189c341df5f9f63717111f 6742 > gdbm_1.14.1-3_source.buildinfo > Files: > 01420d20557fd495e62978bb9dddfd7c 2122 libs important gdbm_1.14.1-3.dsc > 1dc2100d0f557fa577a0bdab78c7eba5 25932 libs important > gdbm_1.14.1-3.debian.tar.xz > 4c6692759c2dc68dd981e6cefa8d2839 6742 libs important > gdbm_1.14.1-3_source.buildinfo > > Date: Thu, 1 Feb 2018 21:37:27 +0100 > From: Helmut Grohne <hel...@subdivi.de> > To: Debian Bug Tracking System <sub...@bugs.debian.org> > Subject: dietlibc FTCBFS: dietlibc is difficult > User-Agent: Mutt/1.9.2 (2017-12-15) > > Source: dietlibc > Version: 0.34~cvs20160606-7 > User: helm...@debian.org > Usertags: rebootstrap > > dietlibc fails to cross build from source. The ultimate failure arises > when it tries to execute diet for the host architecture. > > So I looked and what I found was very confusing. There are lots of > problems. Let me start by quoting the dietlibc FAQ[1]: > > | Q: Do you have cross compiling support? > | A: Yes. Just type something like "make ARCH=arm CROSS=arm-linux- all". > | For arm, alpha, mips, ppc, sparc and i386, shortcuts exist. You can > | also use "make arm", for example. You still use the same "diet" > | program as for normal compilation, but you can then say > | > | $ diet sparc-linux-gcc -pipe -g -o t t.c > | > | Programs using autoconf can be configured like this: > | > | $ CC="diet sparc-linux-gcc" ./configure --disable-nls > > Unfortunately, the packaging gets this completely wrong. The FAQ says > that you should set ARCH, but the packaging sets MYARCH. In GNU > terminology, ARCH is the host architecture and MYARCH is the build > architecture. Thus the packaging confuses build and host here. > > Next up, it doesn't pass CROSS. The value should be > "${DEB_HOST_GNU_TYPE}-". > > The upstream Makefile expects to be in control of the CC variable. > Unfortunately, most other Makefiles expect not to be in control, so > dh_auto_build passes CC as a command line variable now. This renders > upstream statements such as > > CC+=-D__dietlibc__ > > ineffective (and it should be using CFLAGS anyway). I'm afraid, we > cannot use dh_auto_build here without expecting breakage. > > Then the build wants to run "bin-${MYARCH}/diet". But it doesn't build > that. For cross compiling, one needs another build pass where ARCH and > CROSS are not set. > > Finally, when using dietlibc, one wants the diet program to come from > the build architecture and the library for the host architecture. The > packaging however stuffs both into the same binary package. The typical > fix is to split dietlibc-dev into another package dietlibc-dev-bin. Then > move the diet program there and move it into an architecture-independent > path. Mark dietlibc-dev-bin Multi-Arch: foreign and have dietlibc-dev > depend on it. You can turn the original architecture-dependent paths > into symlinks for backwards-compatibility. > > I tried implementing what I sketched here, but it turned out I was > producing more and more stranger and stranger errors (presumably, > because I don't understand the packaging well enough). Thus I only write > down what I know and hope that you can fix at least some aspects. I'm > happy to help. > > Unfortunately, dietlibc suddenly became part of the bootstrap problem > when gdbm started Build-Depending on it. > > Helmut > > [1] https://www.fefe.de/dietlibc/FAQ.txt
