[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