[Fedora-packaging] how to force rpmbuild to use local libraries?

[Tom "spot" Callaway]

On 08/28/2009 12:22 PM, Krzesimir Nowak wrote:
> Hi,
> 
> I'm using Fedora 11, so all software in repository are stable ones, but
> I'm developing a library using unstable versions of them (e.g. I have
> now glibmm24 2.20, and I need it in version 2.21.3). I have those
> unstable versions installed in my home directory (that is `~/usr/') and
> I'm testing my library on them by using parallel environment provided by
> `jhbuild shell'. I decided to build a package with rpmbuild, but it uses
> `/usr/' path for everything (pkg-config files and such) even if I
> execute it from my parallel environment, so building the package ends
> quickly with message of unmet dependencies or in configure stage, when I
> pass `--nodeps' option. My question is: is there a way to force rpmbuild
> to use libraries in my home directory instead of those in `/usr/'?

Well, to be fair, rpmbuild isn't to blame here. The spec file probably
has something like:

%configure --with-foo --with-bar

That simply invokes configure with a set of sane options (including
pointing to the system library/binary paths). For example, on my rawhide
x86_64 system, %configure evaluates to:

CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic}" ; export CFLAGS ;
  CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic}" ; export CXXFLAGS ;
  FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic -I/usr/lib64/gfortran/modules}" ; export FFLAGS ;
  ./configure --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu \
	--target=x86_64-redhat-linux-gnu \
	--program-prefix= \
	--prefix=/usr \
	--exec-prefix=/usr \
	--bindir=/usr/bin \
	--sbindir=/usr/sbin \
	--sysconfdir=/etc \
	--datadir=/usr/share \
	--includedir=/usr/include \
	--libdir=/usr/lib64 \
	--libexecdir=/usr/libexec \
	--localstatedir=/var \
	--sharedstatedir=/var/lib \
	--mandir=/usr/share/man \
	--infodir=/usr/share/info

Now, if your spec file used "./configure" instead of "%configure", you
could hardcode any of those paths into the spec that you want. It
wouldn't be portable though. Even if that package built, it would still
depend on things not packaged up, and complain on installation.

As a possible alternative, if you can make packages for the unstable
library dependencies, then you can build this package in a chroot where
the unstable libraries are installed. Or, if the libraries have unique
sonames, you should be able to have them both installed in system
locations and eliminate the need for the chroot.

hth,

~spot