[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

i386: Compiling gcc-snapshots from upstream with multiarch-toolchain?

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
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

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 ->

# 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/lib/crt1.o <--- SELF-CREATED symlink
/usr/lib/crti.o <--- SELF-CREATED symlink
/usr/lib/crtn.o <--- SELF-CREATED symlink

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)?

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.

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.

- 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

Reply to: