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/'?
Thanks for your help, Krzem.
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
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
On 08/28/2009 03:41 PM, Krzesimir Nowak wrote:
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.
Yeah, but to be honest, not having the dependencies packaged means that you've already lost portability. :)
~spot
On Fri, 2009-08-28 at 16:26 -0400, Tom "spot" Callaway wrote:
Yeah, but to be honest, not having the dependencies packaged means that you've already lost portability. :)
No, no. Dependencies are packaged, but they are too old, even in Rawhide. I'm wondering if filing a bug mentioning about availability of new unstable upstream releases is good idea.
Krzem
packaging@lists.fedoraproject.org