Recent sid amd64 rpath oddity?

2006-07-18 Thread Simon Huggins
Hi,

On the 3rd May I built libxfce4util and generated
libxfce4util2_4.3.90.1-1_amd64.deb.  This is in the archive exactly as I
built it.  It has a couple of lintian failures that I missed and have since
been fixed in our SVN.

Upstream have released recently and whilst checking these packages more
thoroughly I've fixed up the lintian errors but I've also built the new
package and I noticed that it's defining an rpath.  So I rooted around and
tried to work out why but couldn't really work it out.  Upstream's
libtool and autotools looked recent to me.  If I relibtoolize though
this does go away.

Out of curiousity I rebuilt the previous package i.e. 4.3.90.1-1 again from
the same source files as before but with current sid and this time it fails
with two extra lintian warnings:
W: libxfce4util2: binary-or-shlib-defines-rpath ./usr/lib/libxfce4util.so.2.1.0 
/usr/lib
W: libxfce4util2: binary-or-shlib-defines-rpath ./usr/sbin/xfce4-kiosk-query 
/usr/lib

If I rebuild the same package on i386 current sid then I don't get the rpath
installed.

I guess I have several questions:
- how can the same source package over a few months build
  differently in this way?
- am I really going to have to relibtoolize every xfce package
  before I upload or make them do it themselves? :-/
- how evil is an rpath on /usr/lib anyway?

I'd welcome any testers on amd64 or not and on recent sid or not to narrow
this down.  Or any clues as to how on earth this can happen.

If you do want to relibtoolize then install xfce4-dev-ools and run
xdt-autogen in the package dirrectory.

Thanks.

Simon.

heh, good sigmonster.

-- 
oOoOo Open source is about letting go of complete control. Accept  oOoOo
 oOoOo   the fact that other people are wonderful resources tooOoOo
  oOoOo fixing problems, and let them help you. - Linus Torvalds oOoOo
  htag.pl 0.0.22 ::: http://www.earth.li/~huggie/


signature.asc
Description: Digital signature


Re: Recent sid amd64 rpath oddity?

2006-07-18 Thread Goswin von Brederlow
Simon Huggins [EMAIL PROTECTED] writes:

 Hi,

 On the 3rd May I built libxfce4util and generated
 libxfce4util2_4.3.90.1-1_amd64.deb.  This is in the archive exactly as I
 built it.  It has a couple of lintian failures that I missed and have since
 been fixed in our SVN.

 Upstream have released recently and whilst checking these packages more
 thoroughly I've fixed up the lintian errors but I've also built the new
 package and I noticed that it's defining an rpath.  So I rooted around and
 tried to work out why but couldn't really work it out.  Upstream's
 libtool and autotools looked recent to me.  If I relibtoolize though
 this does go away.

 Out of curiousity I rebuilt the previous package i.e. 4.3.90.1-1 again from
 the same source files as before but with current sid and this time it fails
 with two extra lintian warnings:
 W: libxfce4util2: binary-or-shlib-defines-rpath 
 ./usr/lib/libxfce4util.so.2.1.0 /usr/lib
 W: libxfce4util2: binary-or-shlib-defines-rpath ./usr/sbin/xfce4-kiosk-query 
 /usr/lib

 If I rebuild the same package on i386 current sid then I don't get the rpath
 installed.

 I guess I have several questions:
   - how can the same source package over a few months build
 differently in this way?
   - am I really going to have to relibtoolize every xfce package
 before I upload or make them do it themselves? :-/
   - how evil is an rpath on /usr/lib anyway?

 I'd welcome any testers on amd64 or not and on recent sid or not to narrow
 this down.  Or any clues as to how on earth this can happen.

 If you do want to relibtoolize then install xfce4-dev-ools and run
 xdt-autogen in the package dirrectory.

Your package, or more likely libtool, has different ideas about what
amd64 system library dirs are to what debian has.  Other distributions
use /usr/lib64 and debian has /usr/lib. That confuses libtool into
adding a rpath. The fix is to force libtool to never ever use rpath.
If you can't get libtool to leave well enough alone then use 'chrpath
-d'.

With rpath your package will afaik break when the library moves,
e.g. to /usr/lib64 for biarch systems as we use at my workplace, or
the multiarch /usr/lib/x86_64-linux-gnu directory.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]