Re: rpath issue on 64 bit architectures

[Francesco Namuri <francesco@namuri.it>]

Il giorno 04/dic/07, alle ore 23:01, Russ Allbery ha scritto:

> Francesco Namuri <francesco@namuri.it> writes:
> > Il giorno 04/dic/07, alle ore 01:23, Russ Allbery ha scritto:
>
> > > The problem is that libtool doesn't think that lib64 is on the  
> > > regular
> > > library search path and hence decides that it needs to add rpath,  
> > > which
> > > is broken at several different levels but best avoided by just using
> > > lib.
>
> > at this point, the only way is to patch libtool after the creation...
> > is it a better solution respect at the use of chrpath?
>
> I guess what I don't understand is that I don't think we're seeing  
> this
> with everything in the archive, and lots of other packages also use
> libtool.  Are we seeing this behavior everywhere, or is there  
> something
> different about your package than others?

This is the first time that I see this problem, so I choose the second  
option...
(there is something different in g-p-m) :)

> It may be that upgrading the version of libtool used by the package  
> to the
> current Debian unstable version would fix it, for instance.


ok I'll try to update libtool.

I'm trying to understand well the problem to fix it in the right way and
to propose a good solution to upstream... My doubt is: is it a common
problem of a particular version of libtool? In this case, why we are
seeing it only in gnome-phone-manager and in gwyddion.
(Note that the author of g-p-m has told me that he uses
"stock libtoolm, and automake-1.10 to create the distribution tabrball")
I have thought that this situation could be much common...

But of course the fact that we see this behavior only in this two cases
is indicative... :)

thanks again!

Cheers,
francesco


--
Francesco Namuri
francesco(at)namuri(dot)it   http://namuri.it/
id gpg key: 21A4702A          accipiter@jabber.org

Attachment: PGP.sig
Description: This is a digitally signed message part