FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-22-2012, 05:52 PM
Jonathan Nieder
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120722175210.GA24772@burratino
 
Old 07-23-2012, 08:36 AM
Goswin von Brederlow
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120723083604.GA10263@frosties
 
Old 07-23-2012, 11:44 AM
Jonathan Nieder
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120723114458.GC14294@burratino
 
Old 07-23-2012, 11:58 AM
Ivan Shmakov
 
Default Bug#637232: Multiarch breaks support for non-multiarch toolchain

>>>>> Jonathan Nieder <jrnieder@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 86pq7my9i5.fsf@gray.siamics.net">http://lists.debian.org/86pq7my9i5.fsf@gray.siamics.net
 
Old 07-25-2012, 01:52 PM
Goswin von Brederlow
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120725135202.GA4229@frosties
 
Old 08-02-2012, 12:39 PM
Thorsten Glaser
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.BSM.4.64L.1208021236200.4423@herc.mirbsd.org" >http://lists.debian.org/Pine.BSM.4.64L.1208021236200.4423@herc.mirbsd.org
 

Thread Tools




All times are GMT. The time now is 03:37 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org