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

[Philip Balister]

No prebuilt image has working PyQt, there is a fix in meta-oe master and
I am working on getting it added to dizzy, but some serious surgery was
done to the sip recipe. I need to review the changes to the sip recipe
before the dizzy maintainers will take it.

PyQwt is needed for the slider block. Long term, we want to drop the
need for PyQwt since there are support issues with PyQwt (see emails
from Tom Rondeau).

Sorry for the slow response to this. I was buried in a very strange
issue late last week. I should have some time to work over the sip issue
blocking the dizzy update.

It occurs to me that we (as in the OpenEmbedded people) could use a web
page explaining release branches and development process to people that
are not familiar with how that project works.

Philip

On 03/01/2015 11:31 AM, Larry Van Der Jagt wrote:
> 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:
> 
> https://github.com/Homebrew/homebrew/blob/d291bb8c144eaa328c4537f5e9797d09f45a79df/Library/Formula/pyqt.rb
> 
> give some indication of this as well as information found here:
> 
> http://pyqt.sourceforge.net/Docs/PyQt4/build_system.html
> 
> 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?
> 
> LVDJ
> 
> 
> 
> 
> 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!
>>
>> -Chris
>>
>> 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.
>>>>
>>>> LVDJ
>>>>
>>>>
>>>> --
>>>> 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.
>>
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>