Am Sonntag, den 09.12.2007, 22:33 +0100 schrieb Jan Beyer:
> Leo "costela" Antunes schrieb am 06.12.2007 16:32 Uhr:
> >> I had to do the option for a patch on aclocal.m4 and configure
> >> scripts with dpatch on build-time.
> >>
> >> On aclocal4 and configure the changes are (for each occurrence)
Hi Jan,
Il giorno 09/dic/07, alle ore 22:33, Jan Beyer ha scritto:
Leo "costela" Antunes schrieb am 06.12.2007 16:32 Uhr:
I had to do the option for a patch on aclocal.m4 and configure
scripts with dpatch on build-time.
On aclocal4 and configure the changes are (for each occurrence): -
hardco
Leo "costela" Antunes schrieb am 06.12.2007 16:32 Uhr:
>> I had to do the option for a patch on aclocal.m4 and configure
>> scripts with dpatch on build-time.
>>
>> On aclocal4 and configure the changes are (for each occurrence): -
>> hardcode_into_libs=yes + hardcode_into_libs=no
>>
>> -hardcod
Russ Allbery wrote:
> lintian.debian.org only checks i386.
Oh, now that makes sense!
Guess the obvious sometimes slips by unnoticed :-)
But anyway, I have an amd64 server and a package with the same problem
which chrpath solved, so my argument stands.
Cheers
--
Leo "costela" Antunes
[insert a
"Leo \"costela\" Antunes" <[EMAIL PROTECTED]> writes:
> Are you sure? Check out package 'transmission', it's been using chrpath
> for the last 3 releases (IIRC) without issues on any arch (at least
> according to lintian.debian.org).
lintian.debian.org only checks i386.
--
Russ Allbery ([EMAIL
Anibal Avelar wrote:
> I will recheck it, but I don't have an AMD machine to confirm again
> :(. I Just received this from my package's sponsor that he has a AMD
> machine.
Which of your packages has this problem? I have an amd64 machine and
could do some testing for you, if you want.
> Yes, I d
>
> Are you sure? Check out package 'transmission', it's been using chrpath
> for the last 3 releases (IIRC) without issues on any arch (at least
> according to lintian.debian.org).
> If it's being used correctly and for some reason doesn't work, please
> file a bug to it (as of now it has no bugs
Anibal Avelar wrote:
> On 12/5/07, Leo costela Antunes <[EMAIL PROTECTED]> wrote:
>>
>> - And, of course, using 'chrpath' on debian/rules
>
> No, it doesn't work for AMD. I tried to use chrpath directly to
> binaries files, but it didn't work.
Are you sure? Check out package 'transmission', it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org
iD8DBQFHV2tSzur584O2RlYRAsxcAJ99AUmHrFROoSmXsBqvS1akSZAETACeNOu+
BDVWCCwVC38y6NYe48YEGvw=
=qv4G
-END PGP SIGNATURE-
On 12/5/07, Leo costela
Leo "costela" Antunes wrote:
>
> The way I see it the options for dealing with RPATH are:
>
- And, of course, using 'chrpath' on debian/rules
Cheers
--
Leo "costela" Antunes
[insert a witty retort here]
signature.asc
Description: OpenPGP digital signature
Russ Allbery wrote:
> Francesco Namuri <[EMAIL PROTECTED]> 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
Il giorno 04/dic/07, alle ore 23:01, Russ Allbery ha scritto:
Francesco Namuri <[EMAIL PROTECTED]> 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 need
Francesco Namuri <[EMAIL PROTECTED]> 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
Hi,
and thanks for the help...
Il giorno 04/dic/07, alle ore 01:23, Russ Allbery ha scritto:
Francesco Namuri <[EMAIL PROTECTED]> writes:
I'm thinking this because after the call of ./configure the generated
libtool file contains all the lib variables set to corresponding
lib64
directory e
Francesco Namuri <[EMAIL PROTECTED]> writes:
> I'm thinking this because after the call of ./configure the generated
> libtool file contains all the lib variables set to corresponding lib64
> directory eg (after a call of ./configure):
Yeah, that's broken, don't do that. /usr/lib is the library
Hi,
Il giorno lun, 03/12/2007 alle 01.00 -0300, Felipe Sateler ha scritto:
> Leo "costela" Antunes wrote:
>
> > could implement something like the widely used
> > AC_RELOCATABLE macro to his scripts, to make a '--disable-rpath' option
> > available at configure time.
>
> Is this really needed?
Hi,
Il giorno lun, 03/12/2007 alle 04.38 +0100, Leo "costela" Antunes ha
scritto:
> Francesco Namuri wrote:
> > I would like to know, what in your opinion is the best solution.
> > And then, I am mistaken thinking that the problem is related to the fact
> > that lib64/ is a symlink to lib/ ?
>
>
On 12/03/2007 04:38 AM, Leo "costela" Antunes wrote :
> What you could suggest upstream is that - if he really believes rpath to
> still be useful and doesn't want to completely abandon it as other gnome
> projects have done - he could implement something like the widely used
> AC_RELOCATABLE macro
Leo "costela" Antunes wrote:
> could implement something like the widely used
> AC_RELOCATABLE macro to his scripts, to make a '--disable-rpath' option
> available at configure time.
Is this really needed? Most configure scripts I've dealt with support
the --disable-rpath option, even when they
Francesco Namuri wrote:
> I would like to know, what in your opinion is the best solution.
> And then, I am mistaken thinking that the problem is related to the fact
> that lib64/ is a symlink to lib/ ?
I'm I don't think this is exactly the problem.
RPATH is meant to help/supplant the linker on ru
Hi,
packaging gnome-phone-manager Leo "costela" Antunes made me see that
lintian was complaining about an rpath set to /usr/lib. I've built the
package on i386 and I saw no warnings, but under an amd64 the problem is
present.
I've reported the bug to author thinking about a configure or Makefile
pr
21 matches
Mail list logo
