Your message dated Mon, 27 Jul 2020 18:05:22 +0200 with message-id <2ea4db46667572b33b5148a72025785732318b06.camel@43-1.org> and subject line Re: general: Multiarch breaks support for non-multiarch toolchain has caused the Debian Bug report #637232, regarding i386: Compiling gcc-snapshots from upstream with multiarch-toolchain? to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 637232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637232 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Cc: debian-gcc <debian-gcc@lists.debian.org>
- Subject: i386: Compiling gcc-snapshots from upstream with multiarch-toolchain?
- From: Sedat Dilek <sedat.dilek@googlemail.com>
- Date: Tue, 11 Oct 2011 14:41:10 +0200
- Message-id: <CA+icZUX-m-0sr7VMrKBc75LmasMkDeFP2myD03pBKS85ktXapQ@mail.gmail.com>
- Reply-to: sedat.dilek@gmail.com
Package: libc6-dev Version: 2.13-21 Severity: normal [ CCing debian-gcc ML ] Dear Maintainer, these problems here were already discussed on #multiarch and reported by me (see for example #636116 or #637218), but still exist. I did not check for a while the progress on the issues, so I am sorry for being uninformed and tapping on your nerves by unseen re-reporting. Personally, I am interested in helping to get the issues solved (for me this looks like a multiarch problem, but CCing debian-gcc folks as well). Again I tried to compile a gcc-4.7 snapshot tarball [1] with my (updated) build-script. ### Workaround #1: /usr/include/gnu/stubs-32.h # ls -l /usr/include/gnu/stubs-32.h lrwxrwxrwx 1 root root 32 Sep 5 17:19 /usr/include/gnu/stubs-32.h -> ../i386-linux-gnu/gnu/stubs-32.h # dpkg -S /usr/include/gnu/ libc6-dev-amd64: /usr/include/gnu # dpkg -S /usr/include/i386-linux-gnu/gnu/stubs-32.h libc6-dev: /usr/include/i386-linux-gnu/gnu/stubs-32.h Q: Is it possible to have this symlink when both (libc6-dev-amd64 and libc6-dev) packages are installed? ### Workaround #2: /usr/lib/crt*.o # ls -l /usr/lib/crt*.o lrwxrwxrwx 1 root root 21 Sep 5 18:24 /usr/lib/crt1.o -> i386-linux-gnu/crt1.o lrwxrwxrwx 1 root root 21 Sep 5 18:24 /usr/lib/crti.o -> i386-linux-gnu/crti.o lrwxrwxrwx 1 root root 21 Sep 5 18:24 /usr/lib/crtn.o -> i386-linux-gnu/crtn.o # dpkg -S /usr/lib/i386-linux-gnu/crt*.o libc6-dev: /usr/lib/i386-linux-gnu/crt1.o libc6-dev: /usr/lib/i386-linux-gnu/crti.o libc6-dev: /usr/lib/i386-linux-gnu/crtn.o # dpkg -S /usr/lib64/crt*.o libc6-dev-amd64: /usr/lib64/crt1.o libc6-dev-amd64: /usr/lib64/crti.o libc6-dev-amd64: /usr/lib64/crtn.o # locate crt1.o crti.o crtn.o | grep ^/usr/lib | egrep -v 'gcrt1.o|Mcrt1.o|Scrt1.o' | sort /usr/lib64/crt1.o /usr/lib64/crti.o /usr/lib64/crtn.o /usr/lib/crt1.o <--- SELF-CREATED symlink /usr/lib/crti.o <--- SELF-CREATED symlink /usr/lib/crtn.o <--- SELF-CREATED symlink /usr/lib/i386-linux-gnu/crt1.o /usr/lib/i386-linux-gnu/crti.o /usr/lib/i386-linux-gnu/crtn.o Q: As you can see libc6-dev-amd64 places its crt*.o in /usr/lib64/, so why should libc6-dev NOT (logically) place same files below /usr/lib/ (as symlinks)? CONCLUSION: I am unsure if I should split this bug-report, but both issues affect the same Debian package and could IMHO easily solved by creating appropriate symlinks. NOTE: A succesfully compiled gcc upstream snapshot tarballs is a testcase for me before I start any compilation of a MIPSEL toolchain for a router project called freetz. Regards, - Sedat (dileks) - P.S.: ATTACHMENTS: 1. build-script 2. make logs [1] ftp://sourceware.org/pub/gcc/snapshots/LATEST-4.7/gcc-4.7-20111008.tar.bz2 [2] http://freetz.org -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-rc4-next20110831.9-686-small (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6-dev depends on: ii libc-dev-bin 2.13-21 ii libc6 2.13-21 ii linux-libc-dev 3.0.0-5 Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.6.1-3 ii gcc-4.4 [c-compiler] 4.4.6-11 ii gcc-4.5 [c-compiler] 4.5.3-9 ii gcc-4.6 [c-compiler] 4.6.1-15 ii gcc-4.7 [c-compiler] 20111008-1 <--- SELF-CREATED dummy package (done with equivs) Versions of packages libc6-dev suggests: pn glibc-doc <none> pn manpages-dev <none> -- no debconf informationAttachment: build_gcc-snapshot.sh
Description: Bourne shell scriptAttachment: make.log.xz
Description: Binary dataAttachment: make.log_continue.xz
Description: Binary dataAttachment: make.log_continue-2.xz
Description: Binary dataAttachment: make.log_continue-3.xz
Description: Binary data
--- End Message ---
--- Begin Message ---
- To: 637232-done@bugs.debian.org
- Subject: Re: general: Multiarch breaks support for non-multiarch toolchain
- From: Ansgar <ansgar@debian.org>
- Date: Mon, 27 Jul 2020 18:05:22 +0200
- Message-id: <2ea4db46667572b33b5148a72025785732318b06.camel@43-1.org>
- In-reply-to: <20110809173156.25324.28514.reportbug@volta.aurel32.net>
- References: <20110809173156.25324.28514.reportbug@volta.aurel32.net>
On Tue, 09 Aug 2011 19:31:56 +0200 Aurelien Jarno <aurel32@debian.org> wrote: > Debian has choosen to implement multiarch, which amongs other things, > means that the includes and libraries are moved in a new "multiarch" > path. This breaks some upstream applications and non-Debian toolchain. [...] > I got fed up by people reporting bug on libc6, while this problem results > from a decision Debian to implement multiarch. People should work on > implementing a compatibility wrapper and to make upstream toolchain > multiarch aware. Until this is done, this bug should be kept opened. This was now ~9 years ago and this report had no activity since late 2014. I would hope it is no longer relevant, so I'll close the report. Ansgar
--- End Message ---