Bug#629819: libc6-dev: moving crt1.o crti.o etc. to /usr/lib/triplet breaks external multiarch unaware applications
Aurelien Jarno wrote: Thanks a lot for the tests, I have just done the change in the SVN. Thanks again. For what it's worth (not much :)) I suspect building gcc trunk with ./configure --prefix=$HOME/opt/gcc \ CFLAGS_FOR_TARGET=-g -O2 -B/usr/lib/x86_64-linux-gnu make BOOT_CFLAGS=-g -O2 -B/usr/lib/x86_64-linux-gnu would work in an alternate universe where the gcc subdirs had been relibtoolized with the latest Debian libtool, though because we don't live in such a universe I haven't been able to check. (I simulated that a little by introducing makefile files with a lowercase 'm' like so: include Makefile LIBTOOL = libtool until growing tired of the exercise in the middle of building stage3. The version of libtool in gcc's trunk simply drops -B flags passed to it. Yegh. At least the exercise helped my conscience a little.) -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725031658.GA2350@elie
Bug#629819: libc6-dev: moving crt1.o crti.o etc. to /usr/lib/triplet breaks external multiarch unaware applications
On Thu, Jul 21, 2011 at 11:27:41AM -0500, Jonathan Nieder wrote: Hi, Aurelien Jarno wrote: Do we really need -B on /lib/$arch ? Good point. It would be better to leave that out, because simpler. I included it because it was in the default search path for gcc-4.6. This directory should not be used for linking, only at runtime. Also reading the documentation, it seems -B also does the job for the include files, so maybe we also don't need -I. Testing with gcc-4.2 reveals that you're right, though I'm not sure I understand why. After dealing with libgcc_s.so, using gcc-4.2 -B/usr/lib/$arch to compile a C file that uses ffi.h works fine. Thanks a lot for the tests, I have just done the change in the SVN. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110723214502.gl13...@hall.aurel32.net
Bug#629819: libc6-dev: moving crt1.o crti.o etc. to /usr/lib/triplet breaks external multiarch unaware applications
Aurelien Jarno wrote: What should be done instead is trying to understand why --sysroot doesn't work. Here's a quick patch. It only covers the libc (libc.so, crti.o, etc) part of the problem. The right way to deal with libgcc1 is still being considered at Bug#634821. If someone knows how to expand this advice to include settings for --with-libs and --with-headers when building GCC from source, that would be nice. Index: debhelper.in/libc.NEWS === --- debhelper.in/libc.NEWS (revision 4801) +++ debhelper.in/libc.NEWS (working copy) @@ -10,7 +10,7 @@ multiarch, you might try to pass the following options to your compiler: --I/usr/include/$arch --sysroot /usr/lib/$arch +-I/usr/include/$arch -B/lib/$arch -B/usr/lib/$arch -- Aurelien Jarno aure...@debian.org Sun, 26 Jun 2011 22:28:52 +0200 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110721083330.ga...@elie.gateway.2wire.net
Bug#629819: libc6-dev: moving crt1.o crti.o etc. to /usr/lib/triplet breaks external multiarch unaware applications
On Thu, Jul 21, 2011 at 03:34:11AM -0500, Jonathan Nieder wrote: Aurelien Jarno wrote: What should be done instead is trying to understand why --sysroot doesn't work. Here's a quick patch. It only covers the libc (libc.so, crti.o, etc) part of the problem. The right way to deal with libgcc1 is still being considered at Bug#634821. If someone knows how to expand this advice to include settings for --with-libs and --with-headers when building GCC from source, that would be nice. Index: debhelper.in/libc.NEWS === --- debhelper.in/libc.NEWS(revision 4801) +++ debhelper.in/libc.NEWS(working copy) @@ -10,7 +10,7 @@ multiarch, you might try to pass the following options to your compiler: --I/usr/include/$arch --sysroot /usr/lib/$arch +-I/usr/include/$arch -B/lib/$arch -B/usr/lib/$arch -- Aurelien Jarno aure...@debian.org Sun, 26 Jun 2011 22:28:52 +0200 Do we really need -B on /lib/$arch ? This directory should not be used for linking, only at runtime. Also reading the documentation, it seems -B also does the job for the include files, so maybe we also don't need -I. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110721130032.gf8...@hall.aurel32.net
Bug#629819: libc6-dev: moving crt1.o crti.o etc. to /usr/lib/triplet breaks external multiarch unaware applications
Hi, Aurelien Jarno wrote: Do we really need -B on /lib/$arch ? Good point. It would be better to leave that out, because simpler. I included it because it was in the default search path for gcc-4.6. This directory should not be used for linking, only at runtime. Also reading the documentation, it seems -B also does the job for the include files, so maybe we also don't need -I. Testing with gcc-4.2 reveals that you're right, though I'm not sure I understand why. After dealing with libgcc_s.so, using gcc-4.2 -B/usr/lib/$arch to compile a C file that uses ffi.h works fine. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110721162741.ga16...@elie.gateway.2wire.net
Bug#629819: libc6-dev: moving crt1.o crti.o etc. to /usr/lib/triplet breaks external multiarch unaware applications
Hallo! On Wed, 08 Jun 2011 17:41:58 +0200, Andreas Beckmann deb...@abeckmann.de wrote: the moving of crt1.o, crti.o, ... from /usr/lib to /usr/lib/triplet breaks external applications that are not aware of the new multiarch paths. One such application is GCC from SVN, which now fails to compile with this error: /usr/bin/ld: cannot find crti.o: No such file or directory (seems to happen the first time the stage1 compiler is used to link something). Testing something with gcc-trunk (and eventually bisecting gcc) is something I do quite regularily. In general I like the multiarch idea and don't want to go the road back. So a possible solution I see to make such external applications work again could be the introduction of a libc6-dev-compat package that ships the links /usr/lib/*.o - /usr/lib/triplet/*.o. This package should not be installed by default, but only by the admin knowing what he does. What's the route forward here? (Or has everyone manually added symlinks to /usr/lib/ by now? Grüße, Thomas pgpPdjr6tsREX.pgp Description: PGP signature
Bug#629819: libc6-dev: moving crt1.o crti.o etc. to /usr/lib/triplet breaks external multiarch unaware applications
Hi! Thomas Schwinge wrote: What's the route forward here? (Or has everyone manually added symlinks to /usr/lib/ by now? On this machine, /usr/share/doc/libc6/NEWS.Debian.gz says: | Starting with the eglibc package version 2.13-5, the libraries are | shipped in the multiarch directory /lib/$arch instead of the more | traditional /lib. | | The toolchain in Debian has been updated to cope with that, and most | build systems should be unaffected. If you are using a non-Debian | toolchain to build your software and it is not able to cope with | multiarch, you might try to pass the following options to your | compiler: | | -I/usr/include/$arch --sysroot /usr/lib/$arch I haven't tried it, but maybe that can help. If that doesn't work well, it could be worth tweaking the libc6-dev package or introducing a package with symlinks to help with the transition (reports on experiments in that vein would also be very welcome). -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110705163039.GA28864@elie
Bug#629819: libc6-dev: moving crt1.o crti.o etc. to /usr/lib/triplet breaks external multiarch unaware applications
Package: libc6-dev Version: 2.13-5 Severity: normal Hi, the moving of crt1.o, crti.o, ... from /usr/lib to /usr/lib/triplet breaks external applications that are not aware of the new multiarch paths. One such application is GCC from SVN, which now fails to compile with this error: /usr/bin/ld: cannot find crti.o: No such file or directory (seems to happen the first time the stage1 compiler is used to link something). Testing something with gcc-trunk (and eventually bisecting gcc) is something I do quite regularily. In general I like the multiarch idea and don't want to go the road back. So a possible solution I see to make such external applications work again could be the introduction of a libc6-dev-compat package that ships the links /usr/lib/*.o - /usr/lib/triplet/*.o. This package should not be installed by default, but only by the admin knowing what he does. Andreas -- System Information: Debian Release: wheezy/sid APT prefers oldstable APT policy: (600, 'oldstable'), (600, 'unstable'), (600, 'testing'), (600, 'stable'), (500, 'stable-updates'), (130, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libc6-dev depends on: ii libc-dev-bin 2.13-5 Embedded GNU C Library: Developmen ii libc6 2.13-5 Embedded GNU C Library: Shared lib ii linux-libc-dev2.6.39-1 Linux support headers for userspac Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.6.0-5 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.4-6The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.5-5The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.6-3The GNU C compiler ii gcc-4.5 [c-compiler] 4.5.3-1The GNU C compiler ii gcc-4.6 [c-compiler] 4.6.0-11 The GNU C compiler Versions of packages libc6-dev suggests: pn glibc-doc none (no description available) pn manpages-dev none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110608154158.7533.83848.report...@cake.ae.cs.uni-frankfurt.de
