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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
