[Rpm-maint] rpmbuild error with 4.4.2.2 (but not 4.4.2)

Ralf Corsepius rc040203 at freenet.de
Wed Nov 28 04:08:27 UTC 2007


On Tue, 2007-11-27 at 17:30 +0100, Joachim Worringen wrote:
> Tom "spot" Callaway wrote:
> > On Mon, 2007-11-26 at 22:57 +0100, Joachim Worringen wrote:
> >> -prefix=$RPM_BUILD_ROOT%{disdir}
> > 
> > You're embedding $RPM_BUILD_ROOT in your prefix. This is almost
> > certainly the cause of your problem, as it is then getting embedded in
> > all of your built files.
> > 
> > You want to instead pass DESTDIR=$RPM_BUILD_ROOT to make install.
> 
> Thanks for the hint. What I actually did now (because we don't install 
> to system default locations, but to /opt/DIS by default) was:
> 
> %build
> configure --prefix=/opt/DIS ...
> make
> 
> %install
> make install DESTDIR=$RPM_BUILD_ROOT
> 
> I assume that the content of $RPM_BUILD_ROOT, which check-buildroot 
> didn't like, came into the libraries that we build with libtool.
Nope. The cause is you installing into a directory (--prefix) rooted at
$RPM_BUILD_ROOT.

>  Maybe 
> with rpath? 
Nope, this is a secondary effect, but not the cause. libdir normally is
being derived from $prefix, libtool-added rpath's normally are being
derived from $libdir, so the rpath issue you see is a side-effect of
using a prefix rooted at $RPM_BUILD_ROOT.

>  I've seen that rpath is considered evil.
When being used correctly, there is nothing wrong with using rpath (When
installing libs into into /opt/<name>/lib or similar rpaths really make
sense). 

In your case, it's your final binaries receiving incorrect paths
hard-coded into it. rpath is visible, but it's very likely your binaries
received further of them, getting into the binaries undiagnosed.

Ralf





More information about the Rpm-maint mailing list