[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Python errors running flowgraph - first attempt

From: Larry Van Der Jagt
Subject: Re: [Discuss-gnuradio] Python errors running flowgraph - first attempt
Date: Sun, 1 Mar 2015 14:31:49 -0500

I don't have a solution for this yet either, but I have made some "progress".  I decided to try and build PyQwt-5.2.0 and see what happened.

Summarizing things we already found:

The starting point for this effort was an SD Card newly generated from the sdimage-gnuradio-demo-direct.xz file that Phillip posted at:

http://files.ettus.com/e3xx_images/beta/dizzy-test/   the other day.  As one would expect once I modifed /etc/ssh/sshd_config, setting X11Forwarding to yes and reset X I could X in and run GRC from my 14.04 Ubuntu VM.

The first thing I noted was that:

1) There are spurious \n's after the *'s in the file /usr/lib/python2.7/site-packages/PyQt4/Qt.py in the instance that is loaded on the E310 that need to be removed in order to not cause an error.

2) In order to run GRC you need to run it with LD_PRELOAD="/usr/lib/libQtDeclarative.so.4.8.6 /usr/lib/libQtSvg.so.4.8.6 /usr/lib/libQtXml.so.4.8.6 /usr/lib/libQtWebKit.so.4.9.4" gnuradio-companion

This get you to the point where running a flowgraph with QtGUI widgets in it complains that the is no QWT

First, when one tries to install the PyQwt-5.2.0 code by running:

python configure.py -Q ../qwt-5.2

A message is generated by configure.py that indicates "Requires at least PyQt-4.2 and it's development tools".  This appeared to be a result of a change in the way PyQt4 pyqtconfig is dealt with from version to version.  The notes on pyqtconfig in this link:


give some indication of this as well as information found here:


This I got past by placing a copy of pyqtconfig.py that I found in my Ubuntu 14.04 VM version implementation into the E310's

/usr/lib/python2.7/site-packages/PyQt4 directory

I also found that when I tried to run pyqtconfig.py from the command line it complained about not having sipconfig.py and so I found a copy of sipconfig.py and sipconfig-nd.py on the Ubuntu 14.04 VM version and put them in the /usr/lib/python2.7/site-packages on the E310.

This got me farther on the path towards trying to build PyQwt on the E310, but issues still remained further downstream of the "Requires at least PyQt-4.2 and it's development tools" message.

I believe this was all that was required to get past the invalid version message.  Although I also copied the folder Qwt5 from /usr/share/sip/PyQt4 to a new folder on the E310 by that name in that location and I copied the file folder named Qwt5 from the /usr/lib/python2.7/dist-packages/Pyqt4 folder to the /usr/lib/python2.7/site-packages/PyQt4 directory on the E310 ... I knew that the two .so files (_iqt.so and Qwt.so) would likely not work because of a need to crosscompile them but  I figured, Python is Python ...  Ididn't copy any .pyc files figuring they would get generated automatically and they were.

Once I had done these things I did in fact get past the "Missing Qwt5 message in GRC, but as expected I came to the message about the invalid ELF format of the .so files.

I was hoping to find the .so files on one of my SD cards from Zedboard or from the original release version of the E310 code, but neither of these appear to have PyQt4 on them at all.

As I have been unable to get the build complete, even on the 14.04 VM natively I thought I'd go back to trying to do this in preparation for trying to crosscompile the missing .so files.

I didn't keep real good notes on what hurtles I faced with this, but I got to the point where python configure.py -Q ../qwt-5.2 was failing with:

sip:Unable to find file QtCore/QtCoremod.sip  SIP failed to generate C++ code,
I found that I needed to sudo apt-get install python-qt4-dev and once I did this the process ran to completion and I was able to 'make' and 'sudo make install'  and I am able to run QTGUI Widgets on the native GRC implementation.

So now the issue is seeing if I can get the cross compilation going ...

Hope this saves someone some time .... Chris, is your "Fm Broadcast Tutorial" in the Public domain somewhere?


On Sun, Mar 1, 2015 at 10:13 AM, Chris Hallinan <address@hidden> wrote:
I never had time to make progress on Qwt so I just removed the Qwt
widgets from my flow graph and used other ones.  Hoping to find time
this week to work on a PyQwt recipe for OE, not sure what other things
on my schedule might thwart those plans ;)

No guarantees that even if I manage to get Qwt built, it won't have
runtime issues. I'm a python newbie, too!

I built a dizzy-based image and I now have gqrx and my FM broadcast
tutorial running on my embedded x86_64 target.  Need to find time to
make more progress on the project soon!


On Fri, Feb 27, 2015 at 12:11 PM, Tom Rondeau <address@hidden> wrote:
> Sorry that I have no insight into this right now, but I wanted to follow up
> and see if there was any progress made on this problem?
> Tom
> On Mon, Feb 9, 2015 at 11:28 AM, Larry Van Der Jagt <address@hidden>
> wrote:
>> Thanks:
>> The info Chris sent along has helped to move this along although at this
>> point I still don't have a solution or a root cause.
>> The library that issues the error message is
>> /usr/lib/python2.7/site-packages/PyQt4/QtDeclarative.so and the symbol it
>> complains about is _ZTI16QDeclarativeView
>> When you Readelf this file you find:
>> Dynamic section at offset 0x40728 contains 29 entries:
>>   Tag        Type                         Name/Value
>>  0x00000001 (NEEDED)                     Shared library: [libQtGui.so.4]
>>  0x00000001 (NEEDED)                     Shared library: [libQtCore.so.4]
>>  0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
>>  0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
>>  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
>>  0x0000000e (SONAME)                     Library soname:
>> [libQtDeclarative.so.1]
>> and
>> 00040128  0000b202 R_ARM_ABS32       00000000   _ZTI16QDeclarativeView
>> and
>>    178: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND _ZTI16QDeclarativeView
>> There is also a library in /usr/lib that is libQtDeclarative.so.4.8.6 that
>> has symbolic links to it named libQtDeclarative.so, .so.4 and .so.4.8.  I
>> though that if I added one for libQtDeclarative.so.1 this might fix the
>> issue, but it did not.
>> When you readelf libQtDeclarative.so.4.8.6 you find:
>> Dynamic section at offset 0x2ce040 contains 34 entries:
>>   Tag        Type                         Name/Value
>> 0x00000001 (NEEDED)                     Shared library: [libQtScript.so.4]
>> 0x00000001 (NEEDED)                     Shared library: [libQtSql.so.4]
>> 0x00000001 (NEEDED)                     Shared library:
>> [libQtXmlPatterns.so.4]
>> 0x00000001 (NEEDED)                     Shared library: [libQtGui.so.4]
>> 0x00000001 (NEEDED)                     Shared library:
>> [libQtNetwork.so.4]
>> 0x00000001 (NEEDED)                     Shared library: [libQtCore.so.4]
>> 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
>> 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
>> 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
>> 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
>> 0x0000000e (SONAME)                     Library soname:
>> [libQtDeclarative.so.4]
>> and
>> 002d0c94  0009ef02 R_ARM_ABS32       002d0c80   _ZTI16QDeclarativeView
>> 002d0d8c  0009ef02 R_ARM_ABS32       002d0c80   _ZTI16QDeclarativeView
>> and
>> 2543: 002d0c80    12 OBJECT  GLOBAL DEFAULT   20 _ZTI16QDeclarativeView
>> I also tried copying /usr/lib/libQtDeclarative.so.4.8.6 to the
>> /usr/lib/python2.7/site-packages/pyQt4 directory as libQtDeclarative.so.1 to
>> no avail.
>> I tried calling gnuradio-companion with
>> LD_PRELOAD=/usr/lib/libQtDeclarative.so.4.8.6 gnuradio-companion and this
>> let the process proceed a little further this time the undefined symbol is
>> in line 11 of QT.py in QTSvg.so and is _ZTI10QSvgWidget.
>> I will keep drilling down on this, but thought I might post first just in
>> case someone recognizes the real issue and perhaps it can be fixed with a
>> simple adjustment to the environment.
>> With respect to the concept that GRC is not really something to run on the
>> embedded processor, that's surely valid, but unless I do not understand how
>> these pieces work, if the QT GUI can run you can't get graphical elements to
>> work even in the produced Python code and that seriously reduces the utility
>> of the embedded device.
>> All comments and direction are appreciated.
>> --
>> Larry Van Der Jagt
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Life is like Linux - it never stands still.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]