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 information
Attachment:
build_gcc-snapshot.sh
Description: Bourne shell script
Attachment:
make.log.xz
Description: Binary data
Attachment:
make.log_continue.xz
Description: Binary data
Attachment:
make.log_continue-2.xz
Description: Binary data
Attachment:
make.log_continue-3.xz
Description: Binary data