Re: [Discuss-gnuradio] compile failure of svn head with slightly old install
On Fri, Feb 23, 2007 at 10:56:34PM -0500, Greg Troxel wrote: Eric Blossom [EMAIL PROTECTED] writes: Jonathan Corgan wrote: On my main development system (Linux Ubuntu 6.10), I normally do a 'make uninstall' to clean out the system directories of related libraries, .py files, .h files, etc. Then I do a 'make distclean' inside the tree, to remove all the old cruft. Only then do I do the usual ./bootstrap, ./configure, etc. I did make uninstall, clean, make and it built. But I'd say it's a bug if you have to uninstall first. Agreed. I'm not in the habit of uninstalling, unless I'm trying to confirm that an install on a virgin machine is working. I can't trivially reproduce this first, but it seems to be mblock's use of pmt that's troublesome. This could be just the only user of functions that changed signature, though. If anything, I suspect problems with how we're specifying inter-library dependencies. Since this used to work under NetBSD and now has a problem, I'm suspicious of a couple of changes that recently went in that were supposed to fix something related to library dependencies on Cygwin/MinGW. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On Sat, Feb 24, 2007 at 04:00:25PM +1030, Berndt Josef Wulf wrote:
G'day,
I've successfully built and tested gnuradio-3.0.3rc1 with pkgsrc see below:
Glad to see that it's working.
barossa: {376} make install
=== Checking for vulnerabilities in gnuradio-3.0.3rc1
=== Installing for gnuradio-3.0.3rc1
= Automatic manual page handling
= Registering installation for gnuradio-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-jack-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-oss-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-portaudio-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-core-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-core-docs-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-examples-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-gsm-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-howto-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-radio-astronomy-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-trellis-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-usrp-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-video-sdl-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-wxgui-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package usrp-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package usrp-docs-3.0.3rc1
barossa: {377}
BTW: Is there any particular reason why gr-howto-write-a-block is standalone
and not part of the gnuradio distribution? Seems odd
Yes. It's designed to illustrate how to build modules outside of the
main tree.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error make usrp
On Sat, Feb 24, 2007 at 01:38:43PM +0700, [EMAIL PROTECTED] wrote: Hi, everyone. I have problems with installing usrp when i give a command make. The error like this: [EMAIL PROTECTED] usrp-0.12]# make make all-recursive make[1]: Entering directory `/home/usrp/usrp-0.12' Making all in config make[2]: Entering directory `/home/usrp/usrp-0.12/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/usrp/usrp-0.12/config' Making all in host make[2]: Entering directory `/home/usrp/usrp-0.12/host' Making all in misc make[3]: Entering directory `/home/usrp/usrp-0.12/host/misc' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/usrp/usrp-0.12/host/misc' Making all in lib make[3]: Entering directory `/home/usrp/usrp-0.12/host/lib' make all-am make[4]: Entering directory `/home/usrp/usrp-0.12/host/lib' if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../host/lib -I../../firmware/include -g -O2 -Wall -Woverloaded-virtual -MT fusb_linux.lo -MD -MP -MF .deps/fusb_linux.Tpo -c -o fusb_linux.lo fusb_linux.cc; \ then mv -f .deps/fusb_linux.Tpo .deps/fusb_linux.Plo; else rm -f .deps/fusb_linux.Tpo; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../host/lib -I../../firmware/include -g -O2 -Wall -Woverloaded-virtual -MT fusb_linux.lo -MD -MP -MF .deps/fusb_linux.Tpo -c fusb_linux.cc -fPIC -DPIC -o .libs/fusb_linux.o fusb_linux.cc:30:28: error: linux/compiler.h: No such file or directory make[4]: *** [fusb_linux.lo] Error 1 make[4]: Leaving directory `/home/usrp/usrp-0.12/host/lib' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/usrp/usrp-0.12/host/lib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/usrp/usrp-0.12/host' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/usrp/usrp-0.12' make: *** [all] Error 2 [EMAIL PROTECTED] usrp-0.12]# Can someone help me? Thanks mahendra Use up-to-date usrp code. This was fixed long ago. Note that usrp-0.12 is not current. See http://gnuradio.org/trac/wiki for pointers to svn and/or tarballs. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] compile failure of svn head with slightly old install
On Feb 23, 2007, at 7:20 PM, Eric Blossom wrote: The build tree should be linking against the build tree (non-installed) libs. This was the issue I came up against when working on the 3.0 release branch recently - I had a previous install of the GR trunk to which the current compile was trying to link. Since the 3.0 release doesn't know about libgromnithread, while the trunk relies upon it, the branch wouldn't compile since it was trying to link against non- built tree libraries. Once I removed the trunk's install everything went OK ... I really have no idea it was still around, since I had already uninstalled it but apparently some of the files didn't get removed by the uninstaller. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NTSC Receiver
Hi - Tried to run with following error output ... thoughts? thanks, Doug ./usrp_tv_rcv_testingNTSC.py -R A -d 8 -f 76 Using RX d'board A: TV Rx Rev 3 width:508 height:262 d_output_buffer_size:133096 LEADING_EDGE_DETECTION_THRESHOLD: 0.9 TRAILING_EDGE_DETECTION_THRESHOLD: 0.3 SDL screen_mode 32 bits-per-pixel SDL overlay_mode 842094169 Traceback (most recent call last): File ./usrp_tv_rcv_testingNTSC.py, line 400, in ? app = stdgui.stdapp (tv_rx_graph, USRP TV RX black-and-white) File /usr/local/lib/python2.4/site-packages/gnuradio/wxgui/stdgui.py, line 36, in __init__ wx.App.__init__ (self, redirect=False) File /usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core.py, line 7700, in __init__ self._BootstrapApp() File /usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core.py, line 7352, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /usr/local/lib/python2.4/site-packages/gnuradio/wxgui/stdgui.py, line 39, in OnInit frame = stdframe (self.flow_graph_maker, self.title, self._nstatus) File /usr/local/lib/python2.4/site-packages/gnuradio/wxgui/stdgui.py, line 60, in __init__ self.panel = stdpanel (self, self, flow_graph_maker) File /usr/local/lib/python2.4/site-packages/gnuradio/wxgui/stdgui.py, line 81, in __init__ self.fg = flow_graph_maker (frame, self, vbox, sys.argv) File ./usrp_tv_rcv_testingNTSC.py, line 188, in __init__ self.connect (self.src, self.am_demod, self.agc, self.ntsc_detector,self.dst) File /usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py, line 115, in connect self._connect (points[i-1], points[i]) File /usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py, line 120, in _connect self._connect_prim (s, d) File /usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py, line 126, in _connect_prim self._check_valid_dst_port (dst_endpoint) File /usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py, line 225, in _check_valid_dst_port self._check_port (dst_endpoint.block.input_signature(), dst_endpoint.port) File /usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py, line 230, in _check_port if signature.max_streams () == -1: # infinite AttributeError: 'PySwigObject' object has no attribute 'max_streams' swig/python detected a memory leak of type 'gr_io_signature_sptr *', no destructor found. Daniel Garcia-5 wrote: Hello, I've completed a prototype for an NTSC decoder blockset for gnu radio. It's not very sophisticated but it lets you see video on the screen using gr-video-sdl. My development platform is Ubuntu 6.10 x86. The signal starts out by using a custom AGC which simply scales the samples by dividing all samples by a local maximum. This puts most of the samples in the 0 to 1.0 range. Then the frame detector uses a simple threshold method to determine when pulses begin and end. The length of time between pulses is used to determine the type of pulse. A simple state machine keeps the output buffered correctly so the screen doesn't get out of whack. Current features: * Black/White reception (vertical and horizontal sync) * Contrast/Brightness adjustment (still a little buggy) Planned features: * automatic black level * color * stereo audio * better sync detection * documentation Any feedback would be appreciated. http://www.danielgarcia.info/thesis/ http://www.danielgarcia.info/thesis/files/gr-video-analog.tgz -Daniel Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://www.nabble.com/NTSC-Receiver-tf3280240.html#a9136974 Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation error and fftw make error
Liu Xin wrote: Sorry for the confusion. My program jammer.py got Segmentation error and stopped. Now I am trying to rebuild fftw_3.0.1 (since from previous list in this group, some one suggested to rebuild fftw without --enable-sse), it cannot pass through the make :( Is your CPU fan spinning? -Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation error and fftw make error
Thank you for the reply, Dan. Yes, the fan works fine. Best, Xin On Sat, 24 Feb 2007, Dan Halperin wrote: Liu Xin wrote: Sorry for the confusion. My program jammer.py got Segmentation error and stopped. Now I am trying to rebuild fftw_3.0.1 (since from previous list in this group, some one suggested to rebuild fftw without --enable-sse), it cannot pass through the make :( Is your CPU fan spinning? -Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FPGA Questions
Hi all, I have dived into the fpga code and I have now much clearer picture of what is going on, but also much more questions :) The Tx CORDIC is disabled in the code I checked out. Why? I have failed to find a description of how to control the AD9862 chip on the Analog Device web site. Where is this documented? I would like to be able to choose the power level and the channel used to transmit every packets. To choose the channel, is it possible to tweak the CIC Decimating filter to slightly alter the signal frequency or is it a better idea to do it in the AD9862? How can I choose the power level? To me, it looks like this job has to be done on the daughter board. Best regards, Thibaud ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FPGA Questions
On 2/24/07, Thibaud Hottelier [EMAIL PROTECTED] wrote: Hi all, I have dived into the fpga code and I have now much clearer picture of what is going on, but also much more questions :) The Tx CORDIC is disabled in the code I checked out. Why? I could be wrong, but I think the TX CORDIC is disabled due to the fact that the samples being delivered over USB are already complex. Any other frequency translation is done within the AD9862 transmit path. Anyone can feel free to correct me if I am wrong. I have failed to find a description of how to control the AD9862 chip on the Analog Device web site. Where is this documented? http://www.analog.com/UploadedFiles/Data_Sheets/AD9860_9862.pdf I would like to be able to choose the power level and the channel used to transmit every packets. To choose the channel, is it possible to tweak the CIC Decimating filter to slightly alter the signal frequency or is it a better idea to do it in the AD9862? How can I choose the power level? To me, it looks like this job has to be done on the daughter board. By channel, do you mean I/Q or do you mean specific frequencies? You should always drive the baseband signal going out to the AD9862 to full scale to minimize quantization noise - but transmit power should be controlled via an auxiliary DAC that is on the AD9862 and being sent to the daughterboard. Does that make sense? On a side note, the CIC filters on the TX side are interpolating - not decimating. Best regards, Thibaud Good luck, Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems attenuating in software - solution?
Dan Halperin wrote: Eric Blossom wrote: Dan, how are you controlling the receiver h/w gain? .. uh? Are there controls for that? Are there examples where they are used? Again, what controls are there for controlling the receiver h/w gain? I only see the set_pga() function in usrp_basic.cc. -Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] calling python from C/C++
G'day, where can I find a simple working example that demonstrates how to create and call a python function from C/C++? I've written an eventhandler for the powermate device in C++ and want to call the relevant python eventhandlers. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems attenuating in software - solution?
On Sat, Feb 24, 2007 at 03:33:34PM -0800, Dan Halperin wrote: Dan Halperin wrote: Eric Blossom wrote: Dan, how are you controlling the receiver h/w gain? .. uh? Are there controls for that? Are there examples where they are used? Again, what controls are there for controlling the receiver h/w gain? I only see the set_pga() function in usrp_basic.cc. -Dan Actually, you want to be using u.subdev.set_gain(...). It's a higher-level interface that knowns how do deal with the concatenation of the PGA in the AD9862 and any daughterboard specific gain that may be controlable. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] calling python from C/C++
On Sun, Feb 25, 2007 at 10:07:57AM +1030, Berndt Josef Wulf wrote:
G'day,
where can I find a simple working example that demonstrates how to create and
call a python function from C/C++? I've written an eventhandler for the
powermate device in C++ and want to call the relevant python eventhandlers.
cheerio Berndt
gr_feval.{h,cc,i} and the matching QA code.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Interfacing USRP through LabView..........
Hi Kshitij I just wonder you figured out how to program the USRP with labview ,cause i'm using Simulink to program it . Why you want to use Instrument Control Toolbox? Best Ayman Shalaby ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] TX modulator shadow?
Hey all,
I was wondering what the following does when initializing the host end of the
transmit chain:
for (int i = 0; i MAX_CHAN; i++){
d_tx_modulator_shadow[i] = (TX_MODULATOR_DISABLE_NCO
| TX_MODULATOR_COARSE_MODULATION_NONE);
...
}
Thanks :)
- George
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FPGA Questions
On Sat, Feb 24, 2007 at 05:13:22PM -0500, Brian Padalino wrote: On 2/24/07, Thibaud Hottelier [EMAIL PROTECTED] wrote: Hi all, I have dived into the fpga code and I have now much clearer picture of what is going on, but also much more questions :) The Tx CORDIC is disabled in the code I checked out. Why? I could be wrong, but I think the TX CORDIC is disabled due to the fact that the samples being delivered over USB are already complex. Any other frequency translation is done within the AD9862 transmit path. Anyone can feel free to correct me if I am wrong. You are correct ;) I have failed to find a description of how to control the AD9862 chip on the Analog Device web site. Where is this documented? http://www.analog.com/UploadedFiles/Data_Sheets/AD9860_9862.pdf I would like to be able to choose the power level and the channel used to transmit every packets. To choose the channel, is it possible to tweak the CIC Decimating filter to slightly alter the signal frequency or is it a better idea to do it in the AD9862? The CIC interpolator doesn't perform freq translation. If you want to change the channel, you'll want to issue the equivalent of a tune command (probably several sub-operations inband) immediately prior to sending the samples for the packet. Yes, I know you're waiting for me to flush out the packet format. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TX modulator shadow?
On Sat, Feb 24, 2007 at 08:42:35PM -0500, George Nychis wrote:
Hey all,
I was wondering what the following does when initializing the host end of
the transmit chain:
for (int i = 0; i MAX_CHAN; i++){
d_tx_modulator_shadow[i] = (TX_MODULATOR_DISABLE_NCO
| TX_MODULATOR_COARSE_MODULATION_NONE);
...
}
Thanks :)
- George
It keeps us from having to make a round-trip to the AD9862 over the
USB when we need to know the current contents of a particular
register. The registers in question contain info that may come from
different sources. In this particular case, AD9862 register 20
contains bits for Negative Fine Tune, Fine Mode, Real Mix,
Negative Coarse Tune, and Coarse Modulation.
We want to be able to do a read-modify-write without having to pay
the overhead for the read.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NTSC Receiver
It looks like it does not make a difference. I tried it and it correctly despite the missing M suffix. -Daniel - Original Message From: Robert Cicconetti [EMAIL PROTECTED] To: GNURadio Discussion List discuss-gnuradio@gnu.org Sent: Friday, February 23, 2007 5:52:05 PM Subject: Re: [Discuss-gnuradio] NTSC Receiver On 2/23/07, John Clark [EMAIL PROTECTED] wrote: Daniel Garcia schrieb: can you send me the output from the console? and the command line you used. -Daniel This is what I get: ./usrp_tv_rcv_testingNTSC.py -n -f 477.25 -d 26 This may be a stupid question, but does it matter that the frequency specified there does not have the M suffix that the example webpage uses? ./usrp_tv_rcv_testingNTSC.py -n -f 477.25 -d 26 ./usrp_tv_rcv_testingNTSC.py -n -f 481.25M -d 26 R C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NTSC Receiver
On Sat, Feb 24, 2007 at 11:21:08AM -0800, DJCarlson wrote: Hi - Tried to run with following error output ... thoughts? thanks, Doug ./usrp_tv_rcv_testingNTSC.py -R A -d 8 -f 76 Using RX d'board A: TV Rx Rev 3 width:508 height:262 d_output_buffer_size:133096 LEADING_EDGE_DETECTION_THRESHOLD: 0.9 TRAILING_EDGE_DETECTION_THRESHOLD: 0.3 SDL screen_mode 32 bits-per-pixel SDL overlay_mode 842094169 Traceback (most recent call last): File ./usrp_tv_rcv_testingNTSC.py, line 400, in ? app = stdgui.stdapp (tv_rx_graph, USRP TV RX black-and-white) File /usr/local/lib/python2.4/site-packages/gnuradio/wxgui/stdgui.py, /usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py, line 230, in _check_port if signature.max_streams () == -1: # infinite AttributeError: 'PySwigObject' object has no attribute 'max_streams' swig/python detected a memory leak of type 'gr_io_signature_sptr *', no destructor found. As far as I know, every occurence of this has been a result of partial stale installations of GNU Radio, or multiple overlapping installations. My suggestions: $ rm -fr /usr/local/lib/python2.4/site-packages/gnuradio $ rm -fr /usr/local/lib/python2.4/site-packages/usrp* $ rm /usr/local/lib/libgnuradio* $ rm /usr/local/lib/libusrp* Then start with a fresh check out from svn into AN EMPTY DIRECTORY, or unpack the latest tarball into AN EMPTY DIRECTORY. See http://gnuradio.org/trac/wiki for directions on getting the code. Also, check your PYTHONPATH and make sure that it's reasonable. Most folks have something like: [EMAIL PROTECTED] mail]$ echo $PYTHONPATH /usr/local/lib/python2.4/site-packages Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NTSC Receiver
Eric Blossom wrote: As far as I know, every occurence of this has been a result of partial stale installations of GNU Radio, or multiple overlapping installations. My suggestions: $ rm -fr /usr/local/lib/python2.4/site-packages/gnuradio $ rm -fr /usr/local/lib/python2.4/site-packages/usrp* $ rm /usr/local/lib/libgnuradio* $ rm /usr/local/lib/libusrp* This is the utility of the 'make uninstall' command, which not only removes the lib stuff but the installed headers, documentation etc. But ever things get out of sync (like installing the release branch over an install from the trunk, etc.), it won't work, and you'd need to do the above at a minimum. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] libtool/linker/dynamic loader stuff
It seems like it's time to fully revist the interlibrary dependency issue, and the related issue of reliably and robustly testing with build tree libs vs install tree libs. My priority order for this working is: Free systems are first priority: * GNU/Linux must work as expected using unmolested libtool. Ubuntu may be broken, and if it is, we need to fully understand why and how it's broken. If it makes sense, we should file a bug upstream with good explanation for the behavior that we expect. I.e., testing with uninstalled libs. * NetBSD must work as expected * OS/X is next (at least their kernel is free) * MinGW/Cygwin/Windows: lowest priority. If we have to break this to fix the others, it's not the end of the world. I'd prefer a solution that works reliably for all, but if it comes down to triage, this one dies first. What working means: We are able to test our apps and Python code in the build tree in a way that is _completely_ independent of whether or not there is an earlier installation of our code or not. I've seen some flaky behavior on some platforms where it appears that we get different behavior depending on whether there's already something in the install path. This usually manifests itself as undefined foo... where foo is the mangled name of a new function or method that is in fact contained in the build tree libs, but isn't contained in the installed libs. When make check is run, the installed libs, if any, MUST NOT BE REFERENCED to resolve any symbols. Likewise, when installed, our libraries should only resolve symbols using the installed libraries. I believe that libtool will do this out of the box. It normally causes stuff to be linked twice: once at compile time, and once again at install time. However, for this to work, we need to do things the libtool way. I'm not sure we're fully compliant. I'm looking for someone who's willing to sort this out and to test on all platforms. To succeed in this venture the person ought to have (or be willing to develop) a solid understanding of how dynamic linking works in general, how libtool works, and what ld flags such as -rpath, -L, and -l do. Understanding how python finds and loads native modules is essential too. OS-specific knowledge of dynamic linking and shared libs on all the platforms would probably come in handy ;) Under Linux, see man ld, man ld-linux.so, man ldd, man ldconfig Under OS/X, don't confuse glibtool with libtool ;) http://www.gnu.org/software/libtool/ http://www.gnu.org/software/libtool/manual.html (You can also build the pdf doc if you download the libtool src) You'll also want to look at the automake docs and see how it interacts with libtool: http://www.gnu.org/software/automake/ http://sources.redhat.com/automake/automake.pdf http://www.gnu.org/software/libtool/manual.html#Using-Automake Relevant environment variables include: LD_LIBRARY_PATH, PYTHONPATH, DYLD_LIBRARY_PATH (os/x) In all of this discussion, please assume libtool 1.5.22. It's the latest stable version (18 December 2005). Any volunteers? Fame and glory awaits! (You don't need to be an existing committer. If you're willing to take this on, I'll set you up with the access you need to do the work.) I'm sure we can find a way to provide access to all the relevant platforms. Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
