Hi,
I creating a spec file for GNU Radio, and I discovered some minor
issues:
-
Standard library paths are hardcoded into some of the libraries. I
use this command in the spec file to fix libtool before building:
sed -i ‘s|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g’
libtool
sed -i ‘s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g’ libtool
-
Install path for some of the python modules are problematic:
/usr/lib64/python2.4/site-packages/init.py
/usr/lib64/python2.4/site-packages/_usrp_prims.la
/usr/lib64/python2.4/site-packages/_usrp_prims.so
/usr/lib64/python2.4/site-packages/usrp_dbid.py
/usr/lib64/python2.4/site-packages/usrp_fpga_regs.py
/usr/lib64/python2.4/site-packages/usrp_prims.py
Would it be possible to move these to a separate subfolder?
Cheers,
Trond D.
2007/3/6, Eric B. [email protected]:
Just out of curiosity, how does everybody else handle this problem?
I suspect that they’re not editing libtool source.
Please take a look at the .spec files for other applications built
with autotools.
I am aware of that this solution looks a bit dirty, but it is actually
taken from the packaging guidelines on the fedoraproject wiki:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544
The message reported by rpmbuild is not an error; it is possible to
ignore it, but I wanted to do the right thing. Thats why I am asking.
–
Trond D.
On Tue, Mar 06, 2007 at 01:38:51PM +0100, Trond D. wrote:
Hi,
I creating a spec file for GNU Radio, and I discovered some minor issues:
- Standard library paths are hardcoded into some of the libraries. I
use this command in the spec file to fix libtool before building:
sed -i ‘s|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g’
libtool
sed -i ‘s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g’ libtool
Just out of curiosity, how does everybody else handle this problem?
I suspect that they’re not editing libtool source.
Please take a look at the .spec files for other applications built
with autotools.
- Install path for some of the python modules are problematic:
/usr/lib64/python2.4/site-packages/init.py
/usr/lib64/python2.4/site-packages/_usrp_prims.la
/usr/lib64/python2.4/site-packages/_usrp_prims.so
/usr/lib64/python2.4/site-packages/usrp_dbid.py
/usr/lib64/python2.4/site-packages/usrp_fpga_regs.py
/usr/lib64/python2.4/site-packages/usrp_prims.py
Would it be possible to move these to a separate subfolder?
Yes, I’ll move the installation of those. It’ll be later today.
Eric
On Tue, Mar 06, 2007 at 01:38:51PM +0100, Trond D. wrote:
Would it be possible to move these to a separate subfolder?
Cheers,
Trond D.
In [4728] on the trunk, I moved these to site-packages/usrpm.
This change could impact user code that’s not in the tree.
In particular, any occurrences of any of:
import usrp_dbid
import usrp_prims
from usrp_fpga_regs import *
should be changed to:
from usrpm import usrp_dbid
from usrpm import usrp_prims
from usrpm.usrp_fpga_regs import *
respectively.
Sorry about the incompatible change, but this does clean up our
installation.
Thanks,
Eric
On Tue, Mar 06, 2007 at 05:42:34PM +0100, Trond D. wrote:
sed -i ‘s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g’ libtool
Just out of curiosity, how does everybody else handle this problem?
I suspect that they’re not editing libtool source.
Please take a look at the .spec files for other applications built
with autotools.
I am aware of that this solution looks a bit dirty, but it is actually
taken from the packaging guidelines on the fedoraproject wiki:
Fedora Packaging Guidelines - Fedora Project Wiki
Very good. I guess they don’t care for --rpath 
The message reported by rpmbuild is not an error; it is possible to
ignore it, but I wanted to do the right thing. Thats why I am asking.
Thanks for you efforts on this. It’ll be great to have an rpm.
Trond D.
Eric
In [4728] on the trunk, I moved these to site-packages/usrpm.
Why usrpm? Why not just usrp?
Matt
On Tue, Mar 06, 2007 at 07:39:45PM -0800, Matt E. wrote:
In [4728] on the trunk, I moved these to site-packages/usrpm.
Why usrpm? Why not just usrp?
Matt
Short answer: because it doesn’t work.
Long answer: because there’s lots of code that does
from gnuradio import usrp
which of course puts a module called usrp in the namespace.
If you then try
from usrp import usrp_dbid
or
import usrp.usrp_dbid
You’re hosed 
Lacking any creativity, I called it usrpm for “usrp module”
Eric