On 17/07/17 14:04, Marcus Müller wrote:

I'd resort to making sure there's nothing old in /usr/local/lib* anymore. Basically, move every file that hasn't been created there since the recompile to a backup location, figure out what's missing after that, and rebuild.

Best regards,

Marcus


On 07/17/2017 03:43 PM, Marcus D. Leech wrote:
On 07/17/2017 03:41 AM, John Shields wrote:
On 17/07/17 05:53, Marcus D. Leech wrote:
On 07/17/2017 12:47 AM, John Shields wrote:

Even after I re-installed pyephem (for python 2) the issue continues i.e. logger_tp undefined and malloc error. GRC is sane in that I can instantiate a USRP source and display it's FFT.


Since the logger issue is a new one (which is to say that my Sunday build did not have the issue) - could I have gotten an inconsistent code set from the system? I would hope not but cannot fathom what changed to give the logger issue? As for the malloc, I presume that somewhere in the universe someone used the Ubuntu upgrade from 14.04 LTS to 16.04 LTS and could still run GNURadio/simple_ra?


If you cd into your simple_ra directory and do:

git log

What is the first git hash that shows up?




_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Hi Marcus,

It shows: commit e113d01251c90a9b93a228c2dd7cb8a609c6bb8e


I decided that perhaps I should get and install the latest gr-ra_block and simple_ra (as of 20 minutes ago). I could pre-install the gr-ra_blocks fine but when I tried a make on the latest simple_ra I got :


john@i7ubuntu:~$ git clone https://github.com/patchvonbraun/simple_ra
Cloning into 'simple_ra'...
remote: Counting objects: 37, done.
remote: Total 37 (delta 0), reused 0 (delta 0), pack-reused 37
Unpacking objects: 100% (37/37), done.
Checking connectivity... done.
john@i7ubuntu:~$ cd simple_ra
john@i7ubuntu:~/simple_ra$ make
Using .:/usr/local/lib/python2.7/dist-packages:/home/john/simple_ra/trunk:/home/john/bin for compile...
grcc -d . simple_ra_receiver.grc
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.001.001-79-g7ac01c7f

Unhandled exception in thread started by <bound method Thread.__bootstrap of <Thread(Thread-1, stopped daemon 140677736593152)>>git describe --abbrev=8 --dirty --always --tags >tmprev.tmp
sed -e s/@@REV@@/`cat tmprev.tmp`/ <simple_ra_receiver.py >tmprec.py
cp tmprec.py simple_ra_receiver.py
rm -f tmprev.tmp tmprec.py
john@i7ubuntu:~/simple_ra$

and the first commit in that directory is: commit 75051fdbb02aedf730905b74d9ef78ba49db56e6


          Kind Regards,


                      John


No idea what's going on there. I just did this myself on my system, and it worked just fine.




_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

So, taking Marcus' advice - there were a couple of old libraries libairspy.so.1.08, libhackrf.so.0.4.0 and libvolk.so.1.2.2 all from May 31 2016 so I removed them as there were current builds of 1.0.9,0.5.0 and 1.3 respectively in the same directory.

Still the malloc problem existed though a reinstall of simple_ra removed the tp_logger issue.

As I mentioned before, I could get a basic UHD source to work OK so I replaced the osmocom source in simple_ra grc with UHD equivalent and re-generated and make install and the application comes up fine with one UHD source (with address from either of my devices - one with GPSDO and one without).

Then I went back and re-enabled the osmocom source but for only 1 channel, it also worked on either N200 though I got 10.2 (the device with the GPSDO) gives a warning : WARN: Block (fix_cc0) max output buffer set to 8192 instead of requested 67273792

Not sure if any of this makes any sense ?


                Kind Regards,


                                   John

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to