Re: Bug#637232: Multiarch breaks support for non-multiarch toolchain
Jonathan Nieder dixit: pcc (Portable C compiler): unfixed - http://bugs.debian.org/638309 Yes, but that was not the main showstopper for pcc. Besides upstream bugs on some architectures (recently, even Linux/amd64 broke again – I’m following pcc dev), the main problem was how to get pcc-libs for the target architecture installed. Since I can now finally use Depends: pcc-libs:i386 on arch-any packages (which was not at first allowed by M-A but got added to dpkg recently), I believe I can go forward some day now and put together new pcc versions for experi- mental that actually make use of M-A. I approximately know how to deal with the pathnames (having worked enough with gcc), so no need to assist at the moment (though, that being said, pcc is lower priority to me than others at the moment – contact me if it’s important to you). bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1208021236200.4...@herc.mirbsd.org
Bug#637232: Multiarch breaks support for non-multiarch toolchain
On Mon, Jul 23, 2012 at 06:44:58AM -0500, Jonathan Nieder wrote: Hi, Goswin von Brederlow wrote: On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote: c) Compatibility wrapper. If someone needs this, feel free to email me and I'll help out however I can. If you write one of those then please make sure it works with gcc, gcc -m32, gcc -m64 and uclibc [...] Let's not get ahead of ourselves. I'm not aware of a wrapper having been written, and I certainly wouldn't want to impose additional requirements on someone trying unless someone interested is providing the patches to support those. If someone writes a wrapper then he has to make sure it doesn't break things that used to work. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120725135202.GA4229@frosties
Bug#637232: Multiarch breaks support for non-multiarch toolchain
On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote: affects 637232 + release-notes quit Hi, Matthias Klose wrote: On 08/09/2011 07:31 PM, Aurelien Jarno wrote: 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. just do it. To be realistic, is anyone actually going to do this? Avenues forward: a) Help upstream authors of toolchain components with hardcoded header and library search paths to implement multiarch. gcc: in progress - http://gcc.gnu.org/PR53468 (thanks, Matthias!) clang: fixed? - http://llvm.org/bugs/show_bug.cgi?id=6541 icc (Intel C++): status? pathcc (PathScale ekopath): status? tcc (Tiny C compiler): fixed - b56edc7b, 2012-05-22 pcc (Portable C compiler): unfixed - http://bugs.debian.org/638309 cmake: fixed - http://public.kitware.com/Bug/view.php?id=12037 What I don't understand is why compilers (which probably means ld from binutils in all cases) won't use ld.so.conf to find the libs. It only does so to find libs linked into libs you link against. So it is used execpt for the verry first level of recursion. Maybe this could be fixed better in a single common point. b) There is a workaround described in libc6/NEWS.Debian.gz which works fine: LIBRARY_PATH=/usr/lib/triplet CPATH=/usr/include/triplet export CPATH LIBRARY_PATH It's probably worth advertising that more widely, for example in the release notes. I find it a bit hard to believe CPATH is needed. That directory has been in use for years and years way before multiarch. Anyone know which compiler needs it? c) Compatibility wrapper. If someone needs this, feel free to email me and I'll help out however I can. If you write one of those then please make sure it works with gcc, gcc -m32, gcc -m64 and uclibc (which brings some wrappers already I believe). It would also be nice to include i486-linux-gnu-* on amd64 and amd64-linux-gnu-* on i386 and similar for other archs. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120723083604.GA10263@frosties
Bug#637232: Multiarch breaks support for non-multiarch toolchain
Hi, Goswin von Brederlow wrote: On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote: a) Help upstream authors of toolchain components with hardcoded header and library search paths to implement multiarch. [...] What I don't understand is why compilers (which probably means ld from binutils in all cases) won't use ld.so.conf to find the libs. It only does so to find libs linked into libs you link against. So it is used execpt for the verry first level of recursion. The ld library path and compiler library path represent different things[*]. [..] Maybe this could be fixed better in a single common point. Something like getconf CPATH and getconf LIBRARY_PATH producing approprite lists for passing to -I and -L to find the system libs and headers without having to parse gcc -print-search-dirs output could be interesting. Is that what you mean? [...] I find it a bit hard to believe CPATH is needed. That directory has been in use for years and years way before multiarch. From the bug log: | Bug#637218 is a similar problem about headers moving. Have you tried it and run into different results? c) Compatibility wrapper. If someone needs this, feel free to email me and I'll help out however I can. If you write one of those then please make sure it works with gcc, gcc -m32, gcc -m64 and uclibc [...] Let's not get ahead of ourselves. I'm not aware of a wrapper having been written, and I certainly wouldn't want to impose additional requirements on someone trying unless someone interested is providing the patches to support those. Hope that helps, Jonathan [*] - One is looking for libfoo.so.5, the other for libfoo.so and libfoo.a. - One points to libs on the arch with running binaries, while the other has libs for the cross-compilation target. - One contains /lib, the other doesn't. - One should not contain compiler-specific directories like /usr/lib/gcc/i486-linux-gnu/4.6, while the other does. - One can be manipulated for special-case tricks with LD_LIBRARY_PATH, the other with LIBRARY_PATH. Declaring that the compiler library path always include the ld library path would not take care of cross-compilation anyway, so my first reaction is to suspect it wouldn't be worth the side-effects. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120723114458.GC14294@burratino
Re: Bug#637232: Multiarch breaks support for non-multiarch toolchain
Jonathan Nieder jrnie...@gmail.com writes: Goswin von Brederlow wrote: What I don't understand is why compilers (which probably means ld from binutils in all cases) won't use ld.so.conf to find the libs. It only does so to find libs linked into libs you link against. So it is used execpt for the verry first level of recursion. The ld library path and compiler library path represent different things[*]. Somehow, I guess that “the ld.so(8) library path” and “the ld(1) library path” were actually meant here. […] -- FSF associate member #7257 http://sf-day.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86pq7my9i5@gray.siamics.net
Bug#637232: Multiarch breaks support for non-multiarch toolchain
affects 637232 + release-notes quit Hi, Matthias Klose wrote: On 08/09/2011 07:31 PM, Aurelien Jarno wrote: 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. just do it. To be realistic, is anyone actually going to do this? Avenues forward: a) Help upstream authors of toolchain components with hardcoded header and library search paths to implement multiarch. gcc: in progress - http://gcc.gnu.org/PR53468 (thanks, Matthias!) clang: fixed? - http://llvm.org/bugs/show_bug.cgi?id=6541 icc (Intel C++): status? pathcc (PathScale ekopath): status? tcc (Tiny C compiler): fixed - b56edc7b, 2012-05-22 pcc (Portable C compiler): unfixed - http://bugs.debian.org/638309 cmake: fixed - http://public.kitware.com/Bug/view.php?id=12037 b) There is a workaround described in libc6/NEWS.Debian.gz which works fine: LIBRARY_PATH=/usr/lib/triplet CPATH=/usr/include/triplet export CPATH LIBRARY_PATH It's probably worth advertising that more widely, for example in the release notes. c) Compatibility wrapper. If someone needs this, feel free to email me and I'll help out however I can. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120722175210.GA24772@burratino
