On Fri, 2009-08-28 at 14:18 -0400, Tom "spot" Callaway wrote:
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.
But using ./configure with manually set options still will use
pkg-config files from /usr/lib/pkgconfig instead of ~/usr/lib/pkgconfig.
So configure stage will fail. Of course, I could define PATH (and other)
environment variable before running ./configure, but that is not what I
want and that blasts any portability away.
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.
It probably will be better if I just wait until newest versions of
libraries are packaged to rawhide (e.g gtkmm24 in rawhide is 2.17.2 and
upstream is 2.17.9). Then I'll try to install rawhide as a second OS (I
already failed at that once) and build a package there.
Thanks for response,
Krzem