Hi Sedat, Sedat Dilek wrote:
> these problems here were already discussed on #multiarch and reported > by me (see for example #636116 or #637218), but still exist. Those look like different bugs. #636116 was about libc6-dev-amd64 failing to unpack! #629819 was about crti.o et al moving to the multiarch location without any warning about the need for build scripts to be adjusted and was fixed by adding a NEWS.Debian.gz describing that need and giving some advice. #637218 was the corresponding problem for headers. Similarly, #634821 was about libgcc_s.so.1 et al moving and breaking old gcc installations without warning and was fixed by adding a Breaks. This time, you are reporting that you needed workarounds to build upstream gcc without patching it or adding special ./configure options: [...] > # 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 [...] > # 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 This is #637232, which is about finding some way to get these things working without making each user spend too much time. More and more headers and libraries (not just those provided by libc6-dev!) are moving to the multiarch locations, so adding symlinks one by one does not seem like a viable strategy for that. See http://bugs.debian.org/637232 for more details. [...] > Again I tried to compile a gcc-4.7 snapshot tarball [1] with my > (updated) build-script. Something that might be useful is to add a "building-premultiarch-toolchain.txt" to libc6-dev or some similar package, explaining how to tell the gcc build system where the bootstrap compiler should look for multiarch libs and headers. Because gcc's configure script is a little insane, this is more complicated than the incantation described in NEWS.Debian.gz, though only cosmetically so. Something like: make FLAGS_FOR_TARGET='-B$(build_tooldir)/bin/ '\ '-B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include '\ '-isystem $(build_tooldir)/sys-include '\ "-B/usr/lib/$DEB_HOST_MULTIARCH" \ "-I/usr/include/$DEB_HOST_MULTIARCH" \ install Yes, this has to be set through a makefile variable, not the configure script, since no one bothered to wire the latter up for it. Yes, presumably the settings that come before '-B/usr/lib/i386-linux-gnu' are needed. They are the default from the toplevel Makefile, and the Makefile does not provide a way to add extra FLAGS_FOR_TARGET without overriding the existing ones. When I tried this[*], I also had set CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET as configure arguments and BOOT_CFLAGS on the "make" command line, but I believe you tested with just FLAGS_FOR_TARGET and found it to work ok. > 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. Good luck! You might also want to look into the gcc-snapshot package, which is already patched to handle the multiarch paths both at build time and at runtime. Will respond to your other message separately. Hope that helps, Jonathan [*] http://bugs.debian.org/637218 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
