discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] GNU Radio via MacPorts Updated


From: Michael Dickens
Subject: Re: [Discuss-gnuradio] GNU Radio via MacPorts Updated
Date: Fri, 12 Nov 2010 18:55:11 -0500

On Nov 12, 2010, at 4:12 PM, Alexandru Csete wrote:
> I don't know if anything got fixed in the macports package but I got a tip to 
> execute a "python_select python26" and reboot. After doing so and installing 
> py26-scipy I could execute the qt_digital.py example included in the gr-qtgui 
> component (see attached screenshot). I have the latest macports packages 
> installed:
> qt4-mac 4.7.1 quartz variant
> py26-pyqt4 4.8.1 (?)

I realized after a bit of testing that Qt 4.7.0 removed the CONFIG option 
"absolute_library_soname" when compared with Qt 4.6.3 -- at least for macx-g++ 
varieties -- as well as changed some other functionality internal to QMake.  
This option sets the "install_name" (self-id) of any created libraries to 
include the full path to the library instead of just the library name.  That 
was the original issue, way back in September, that was causing so many 
problems for those using MacPorts to install GNU Radio and/or its dependencies. 
 If the self-id isn't correct and another library links against it, then the 
new library will contain the incorrect self-id -- thus requiring one to set a 
library search path instead of relying on the libraries themselves (which in 
OSX is just not the way it is done).  So, Qt 4.7.0_1 corrected this and other 
issues with the way QMake works, fixing a bunch of little problems along the 
way that made us developers' lives easier.  I never got back to testing the GNU 
Radio ports to make sure they still work, so I'm glad to hear that they're OK.  
Thanks for the update! - MLD




reply via email to

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