Re: [Discuss-gnuradio] CMake build problem
If I set the CMakeList.txt back to how it used to be and in a new directory re-run cmake, then I get: py_exe /usr/bin/python py_inc /usr/include/python2.7 py_lib /usr/lib/python3.2/config/libpython3.2.so (Which is an interesting mix!) If I now change the py_lib variable to be /u/l/python2.7/c/libpython2.7.so (/usr/bin/python is a sym link to python2.7) and re-generate the make files, it compiles the same way that my modified CMakelist.txt file (i.e. it fails when it gets to gengen_swig_doc.i) so it certainly gets around the python problem. Thanks, Matt Josh Blum writes: > Can you try setting the PYTHON_* variables to the desired setting? > > Here is a screenshot of said variables: http://i.imgur.com/kr99Q.jpg > > -josh > > ___ > 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
Re: [Discuss-gnuradio] CMake build problem
Can you try setting the PYTHON_* variables to the desired setting? Here is a screenshot of said variables: http://i.imgur.com/kr99Q.jpg -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CMake build problem
Tom Rondeau writes: > On Thu, Apr 26, 2012 at 7:30 AM, wrote: > > > > Hi, > > > > I'm running debian unstable on a AMD64 platform and am running into a > > problem which starts right at the top of the build process for a newly > > checkout gnuradio version from git. > > > > Below is output from running cmake: > > > > [snip] > > -- Performing Test HAVE_WARN_ALL > > -- Performing Test HAVE_WARN_ALL - Success > > -- Performing Test HAVE_WARN_NO_UNINITIALIZED > > -- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success > > -- Found PythonLibs: > > optimized;/usr/lib/python3.2/config/libpython3.2.so;debug;/usr/lib/python3.2/config/libpython3.2.so > > (found version "2.7.3rc2") > > -- Found SWIG: /usr/bin/swig2.0 (found version "2.0.4") > > [snip] > > > > So it found that /usr/bin/python is version 2.7.3rc2, but it decides > > to use version 3.2 to link against. This makes the build process > > rather sad later on! (Lots of link failures) > > > > To get around this I changed in CMakeLists.txt > > > > find_package(PythonLibs) > > > > to be > > > > find_package(PythonLibs 2.7.3) > > > > But obviously that'll only work for people running 2.7.3! (I've not > > played with cmake before now, so there might be a simple way to fix > > it) > > > > I'm running cmake version 2.8.7. > > Yes, GNU Radio does not work with Python 3, yet. We will have to make > sure it checks that the Python version is less than 3. Getting it to try and link with the default version of python on the system would also be good. > > > However the build process goes further this time, but now breaks with: > > > > [ 49%] Built target _runtime_swig_doc_tag > > [ 49%] Generating doxygen xml for runtime_swig_doc docs > > [ 49%] Generating runtime_swig_doc.i > > [ 49%] Generating doxygen xml for general_swig_doc docs > > [ 49%] Generating general_swig_doc.i > > [ 49%] Generating doxygen xml for gengen_swig_doc docs > > [ 49%] Generating gengen_swig_doc.i [snip] > > raise member() > > doxyxml.base.Duplicate > > make[2]: *** [gnuradio-core/src/lib/swig/gengen_swig_doc.i] Error 1 > > make[1]: *** > > [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] > > Error 2 > > make: *** [all] Error 2 > > > > > > > > Which I don't know where to start to fix! However I can tell you that > > the file its looking for, /home/./swig/gengen_swig_doc.i doesn't > > exist, but I don't know what should have created it. > > > > > > Thanks, > > > > Matt > > I'm assuming you are running a parallel make? Try just running "make" > with no options and see if that works. This looks like a bug that > we've had for a while that only shows up on occasion and when running > large parallel makes. It generally goes away when you run make again. > We thought we had squashed this one, but it seems to becoming more of > a problem again. > > In the future, you can try something like "make -j8 -k". That will > finish everything it can, even if there are errors with the doc > generation. You can then run "make" after that to capture the rest of > it. > > Tom Yes, I'd been doing a make -j. Rerunning with just 'make' doesn't appear to work - it fell over agaon in the same place. So I created a new build directory, ran cmake in the new directory and then make (with no -j) and it still fails with the above error for gengen_swig_doc.i Thanks, Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CMake build problem
On Thu, Apr 26, 2012 at 7:30 AM, wrote: > > Hi, > > I'm running debian unstable on a AMD64 platform and am running into a > problem which starts right at the top of the build process for a newly > checkout gnuradio version from git. > > Below is output from running cmake: > > [snip] > -- Performing Test HAVE_WARN_ALL > -- Performing Test HAVE_WARN_ALL - Success > -- Performing Test HAVE_WARN_NO_UNINITIALIZED > -- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success > -- Found PythonLibs: > optimized;/usr/lib/python3.2/config/libpython3.2.so;debug;/usr/lib/python3.2/config/libpython3.2.so > (found version "2.7.3rc2") > -- Found SWIG: /usr/bin/swig2.0 (found version "2.0.4") > [snip] > > So it found that /usr/bin/python is version 2.7.3rc2, but it decides > to use version 3.2 to link against. This makes the build process > rather sad later on! (Lots of link failures) > > To get around this I changed in CMakeLists.txt > > find_package(PythonLibs) > > to be > > find_package(PythonLibs 2.7.3) > > But obviously that'll only work for people running 2.7.3! (I've not > played with cmake before now, so there might be a simple way to fix > it) > > I'm running cmake version 2.8.7. Yes, GNU Radio does not work with Python 3, yet. We will have to make sure it checks that the Python version is less than 3. > However the build process goes further this time, but now breaks with: > > [ 49%] Built target _runtime_swig_doc_tag > [ 49%] Generating doxygen xml for runtime_swig_doc docs > [ 49%] Generating runtime_swig_doc.i > [ 49%] Generating doxygen xml for general_swig_doc docs > [ 49%] Generating general_swig_doc.i > [ 49%] Generating doxygen xml for gengen_swig_doc docs > [ 49%] Generating gengen_swig_doc.i > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing error with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. > giving up. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing error with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. > giving up. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing error with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. > giving up. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing error with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. > giving up. > XML parsing error with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. > giving up. > Traceback (most recent call last): > File "/home/matt/gnuradio/docs/doxygen/swig_doc.py", line 294, in > make_swig_interface_file(di, swigdocfilename, custom_output=custom_output) > File "/home/matt/gnuradio/docs/doxygen/swig_doc.py", line 222, in > make_swig_interface_file > make_func = di.get_member(make_name(block.name()), DoxyFunction) > File "/home/matt/gnuradio/docs/doxygen/doxyxml/base.py", line 157, in > get_member > raise member() > doxyxml.base.Duplicate > make[2]: *** [gnuradio-core/src/lib/swig/gengen_swig_doc.i] Error 1 > make[1]: *** > [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error 2 > make: *** [all] Error 2 > > > > Which I don't know where to start to fix! However I can tell you that > the file its looking for, /home/./swig/gengen_swig_do
Re: [Discuss-gnuradio] cmake build not placing lib*.so properly
On 01/13/2012 11:34 AM, Marcus D. Leech wrote:
> On 13/01/12 02:21 PM, Josh Blum wrote:
>>
>> On 01/13/2012 11:01 AM, Marcus D. Leech wrote:
>>
>>> Observe the following directory listing:
>>>
>>> [mleech@localhost ~]$ ls -l /usr/local/lib/libgnuradio-core*
>>> lrwxrwxrwx 1 root root 34 2012-01-13 13:56
>>> /usr/local/lib/libgnuradio-core-3.5.2git.so.0 ->
>>> libgnuradio-core-3.5.2git.so.0.0.0
>>> lrwxrwxrwx 1 root root 34 2012-01-13 13:56
>>> /usr/local/lib/libgnuradio-core.so -> libgnuradio-core-3.5.2git.so.0.0.0
>>> -rwxr-xr-x 1 root root 2108365 2012-01-13 13:45
>>> /usr/local/lib/libgnuradio-core.so.0.0.0
>>>
>>> Notice how libgnuradio-core.so points off to nothingness
>>>
>>> Now, gnuradio-based *applications* seem to be just fine with this, after
>>> running ldconfig.
>>>
>>> But, for example, if you pull something, like gr-stream-tags off of
>>> CGRAN, and try to build the result, it
>>> will barf on a linker error, due to not being able to resolve
>>> "-lgnuradio-core" (and others).
>>>
>>> So the question is, where is cmake getting its notion of how to name
>>> these things, and set up the
>>> symlink hierarchy? If it comes from the ".pc" files, I'll note that
>>> they haven't been updated since
>>> I last ran an autotools build, 5 days ago. Does cmake update the
>>> ".pc" files? How is this
>>> dangling symlink problem happening?
>>>
>>>
>>>
>> The weirdness comes from this code:
>> http://gnuradio.org/cgit/gnuradio.git/tree/cmake/Modules/GrMiscUtils.cmake?h=maint#n151
>>
>> The symlinks looks like this on my system:
>> http://pastebin.com/Q4Vuz8Kb
>>
>> What is your os? I think this line for you isnt changing the library
>> target name to ${target}-${LIBVER}. Does that sound like the issue?
>>
>> set_target_properties(${target} PROPERTIES LIBRARY_OUTPUT_NAME
>> ${target}-${LIBVER} SOVERSION "0.0.0")
>>
>> -Josh
>>
>>
>>
> It's a Fedora-12 32-bit machine. With cmake-2.6.4-5.fc12.i686
>
Thats an old fedora :-)
> That could be the issue, yes. But I'm not a Cmake guy at all.
>
>
>
This is part of our special LIBRARY_EXTRAS mode. You can disable it with
-DLIBRARY_EXTRAS=OFF just so you know, but I think the following patch
will solve the issue...
So, it like cmake 2.6 doesnt have LIBRARY_OUTPUT_NAME, but it does have
OUTPUT_NAME. They are both ways to rename the target, one being specific
to a library and only possible with 2.8 and up. Try this patch:
http://pastebin.com/kXKgJPF7
-josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build not placing lib*.so properly
On 13/01/12 02:21 PM, Josh Blum wrote:
>
> On 01/13/2012 11:01 AM, Marcus D. Leech wrote:
>
>> Observe the following directory listing:
>>
>> [mleech@localhost ~]$ ls -l /usr/local/lib/libgnuradio-core*
>> lrwxrwxrwx 1 root root 34 2012-01-13 13:56
>> /usr/local/lib/libgnuradio-core-3.5.2git.so.0 ->
>> libgnuradio-core-3.5.2git.so.0.0.0
>> lrwxrwxrwx 1 root root 34 2012-01-13 13:56
>> /usr/local/lib/libgnuradio-core.so -> libgnuradio-core-3.5.2git.so.0.0.0
>> -rwxr-xr-x 1 root root 2108365 2012-01-13 13:45
>> /usr/local/lib/libgnuradio-core.so.0.0.0
>>
>> Notice how libgnuradio-core.so points off to nothingness
>>
>> Now, gnuradio-based *applications* seem to be just fine with this, after
>> running ldconfig.
>>
>> But, for example, if you pull something, like gr-stream-tags off of
>> CGRAN, and try to build the result, it
>> will barf on a linker error, due to not being able to resolve
>> "-lgnuradio-core" (and others).
>>
>> So the question is, where is cmake getting its notion of how to name
>> these things, and set up the
>> symlink hierarchy? If it comes from the ".pc" files, I'll note that
>> they haven't been updated since
>> I last ran an autotools build, 5 days ago. Does cmake update the
>> ".pc" files? How is this
>> dangling symlink problem happening?
>>
>>
>>
> The weirdness comes from this code:
> http://gnuradio.org/cgit/gnuradio.git/tree/cmake/Modules/GrMiscUtils.cmake?h=maint#n151
>
> The symlinks looks like this on my system:
> http://pastebin.com/Q4Vuz8Kb
>
> What is your os? I think this line for you isnt changing the library
> target name to ${target}-${LIBVER}. Does that sound like the issue?
>
> set_target_properties(${target} PROPERTIES LIBRARY_OUTPUT_NAME
> ${target}-${LIBVER} SOVERSION "0.0.0")
>
> -Josh
>
>
>
It's a Fedora-12 32-bit machine. With cmake-2.6.4-5.fc12.i686
That could be the issue, yes. But I'm not a Cmake guy at all.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build not placing lib*.so properly
On 01/13/2012 11:01 AM, Marcus D. Leech wrote:
> Observe the following directory listing:
>
> [mleech@localhost ~]$ ls -l /usr/local/lib/libgnuradio-core*
> lrwxrwxrwx 1 root root 34 2012-01-13 13:56
> /usr/local/lib/libgnuradio-core-3.5.2git.so.0 ->
> libgnuradio-core-3.5.2git.so.0.0.0
> lrwxrwxrwx 1 root root 34 2012-01-13 13:56
> /usr/local/lib/libgnuradio-core.so -> libgnuradio-core-3.5.2git.so.0.0.0
> -rwxr-xr-x 1 root root 2108365 2012-01-13 13:45
> /usr/local/lib/libgnuradio-core.so.0.0.0
>
> Notice how libgnuradio-core.so points off to nothingness
>
> Now, gnuradio-based *applications* seem to be just fine with this, after
> running ldconfig.
>
> But, for example, if you pull something, like gr-stream-tags off of
> CGRAN, and try to build the result, it
> will barf on a linker error, due to not being able to resolve
> "-lgnuradio-core" (and others).
>
> So the question is, where is cmake getting its notion of how to name
> these things, and set up the
> symlink hierarchy? If it comes from the ".pc" files, I'll note that
> they haven't been updated since
> I last ran an autotools build, 5 days ago. Does cmake update the
> ".pc" files? How is this
> dangling symlink problem happening?
>
>
The weirdness comes from this code:
http://gnuradio.org/cgit/gnuradio.git/tree/cmake/Modules/GrMiscUtils.cmake?h=maint#n151
The symlinks looks like this on my system:
http://pastebin.com/Q4Vuz8Kb
What is your os? I think this line for you isnt changing the library
target name to ${target}-${LIBVER}. Does that sound like the issue?
set_target_properties(${target} PROPERTIES LIBRARY_OUTPUT_NAME
${target}-${LIBVER} SOVERSION "0.0.0")
-Josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build gnuradio on FreeBSD
I did that and is works, I was just saying that's the only thing that is keeping it from being a simple "./configure && make install". On Thu, Jan 12, 2012 at 8:56 PM, Tom Rondeau wrote: > On Wed, Jan 11, 2012 at 9:27 PM, Andrew Davis wrote: > >> It worked for me other than the qwt so I think so. > > > Just a quick explanation here. Qwt has a very simple, kind of non-standard > installation that's hard to generalize. They don't use standard tools for > auto-discovery of the lib or include paths, so we search the "common" > locations for it. > > You should be able to pass this information to the configure scripts. I > don't know what these parameters are off the top of my head, though. > > Tom > > > > >> On Wed, Jan 11, 2012 at 12:40 PM, Josh Blum wrote: >> >>> >>> >>> On 01/11/2012 06:55 AM, LRK wrote: >>> > >>> > I do not find anything in the README about qt4 or qwt but they seem >>> > to be required for gr-qtgui. >>> > >>> > I used portinstall to install py27-qt4 and several hours and 57 >>> packages >>> > later, cmake could find qt4. >>> > >>> > Then I installed py27-pyqwt and it also installed qwt-5.2.2. Cmake >>> > still would not find qwt. (QWT_FOUND = FALSE). >>> > >>> > I finally tried adding the QWT_INCLUDE_DIRS line below and cmake now >>> > finds qwt and shows gr-qtgui to be built. Trying that next. >>> > >>> > cmake \ >>> > -DCMAKE_INSTALL_PREFIX=$GR_PREFIX \ >>> > -DQWT_INCLUDE_DIRS=/usr/local/include/qwt \ >>> > ../ >>> > >>> > >>> >>> On this branch, I have 2 patches. >>> >>> http://gnuradio.org/cgit/jblum.git/commit/?h=freebsd_tweaks&id=ca3868256079060993ebb643e34b39c558052ce0 >>> >>> 1) make qwt find script better. Its fixes the need to manually specify >>> -DQWT_INCLUDE_DIRS >>> >>> 2) Use CLOCK_GETTIME and not MACH_ABSOLUTE_TIME. Question: Did gr-qtgui >>> compile for you without this change? In other words, does your OS have >>> mach kernel headers? >>> >>> -Josh >>> >>> ___ >>> 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 >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build gnuradio on FreeBSD
On Wed, Jan 11, 2012 at 9:27 PM, Andrew Davis wrote: > It worked for me other than the qwt so I think so. Just a quick explanation here. Qwt has a very simple, kind of non-standard installation that's hard to generalize. They don't use standard tools for auto-discovery of the lib or include paths, so we search the "common" locations for it. You should be able to pass this information to the configure scripts. I don't know what these parameters are off the top of my head, though. Tom > On Wed, Jan 11, 2012 at 12:40 PM, Josh Blum wrote: > >> >> >> On 01/11/2012 06:55 AM, LRK wrote: >> > >> > I do not find anything in the README about qt4 or qwt but they seem >> > to be required for gr-qtgui. >> > >> > I used portinstall to install py27-qt4 and several hours and 57 >> packages >> > later, cmake could find qt4. >> > >> > Then I installed py27-pyqwt and it also installed qwt-5.2.2. Cmake >> > still would not find qwt. (QWT_FOUND = FALSE). >> > >> > I finally tried adding the QWT_INCLUDE_DIRS line below and cmake now >> > finds qwt and shows gr-qtgui to be built. Trying that next. >> > >> > cmake \ >> > -DCMAKE_INSTALL_PREFIX=$GR_PREFIX \ >> > -DQWT_INCLUDE_DIRS=/usr/local/include/qwt \ >> > ../ >> > >> > >> >> On this branch, I have 2 patches. >> >> http://gnuradio.org/cgit/jblum.git/commit/?h=freebsd_tweaks&id=ca3868256079060993ebb643e34b39c558052ce0 >> >> 1) make qwt find script better. Its fixes the need to manually specify >> -DQWT_INCLUDE_DIRS >> >> 2) Use CLOCK_GETTIME and not MACH_ABSOLUTE_TIME. Question: Did gr-qtgui >> compile for you without this change? In other words, does your OS have >> mach kernel headers? >> >> -Josh >> >> ___ >> 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 > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build gnuradio on FreeBSD
It worked for me other than the qwt so I think so. On Wed, Jan 11, 2012 at 12:40 PM, Josh Blum wrote: > > > On 01/11/2012 06:55 AM, LRK wrote: > > > > I do not find anything in the README about qt4 or qwt but they seem > > to be required for gr-qtgui. > > > > I used portinstall to install py27-qt4 and several hours and 57 > packages > > later, cmake could find qt4. > > > > Then I installed py27-pyqwt and it also installed qwt-5.2.2. Cmake > > still would not find qwt. (QWT_FOUND = FALSE). > > > > I finally tried adding the QWT_INCLUDE_DIRS line below and cmake now > > finds qwt and shows gr-qtgui to be built. Trying that next. > > > > cmake \ > > -DCMAKE_INSTALL_PREFIX=$GR_PREFIX \ > > -DQWT_INCLUDE_DIRS=/usr/local/include/qwt \ > > ../ > > > > > > On this branch, I have 2 patches. > > http://gnuradio.org/cgit/jblum.git/commit/?h=freebsd_tweaks&id=ca3868256079060993ebb643e34b39c558052ce0 > > 1) make qwt find script better. Its fixes the need to manually specify > -DQWT_INCLUDE_DIRS > > 2) Use CLOCK_GETTIME and not MACH_ABSOLUTE_TIME. Question: Did gr-qtgui > compile for you without this change? In other words, does your OS have > mach kernel headers? > > -Josh > > ___ > 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
Re: [Discuss-gnuradio] cmake build gnuradio on FreeBSD
On 01/11/2012 06:55 AM, LRK wrote: > > I do not find anything in the README about qt4 or qwt but they seem > to be required for gr-qtgui. > > I used portinstall to install py27-qt4 and several hours and 57 packages > later, cmake could find qt4. > > Then I installed py27-pyqwt and it also installed qwt-5.2.2. Cmake > still would not find qwt. (QWT_FOUND = FALSE). > > I finally tried adding the QWT_INCLUDE_DIRS line below and cmake now > finds qwt and shows gr-qtgui to be built. Trying that next. > > cmake \ > -DCMAKE_INSTALL_PREFIX=$GR_PREFIX \ > -DQWT_INCLUDE_DIRS=/usr/local/include/qwt \ > ../ > > On this branch, I have 2 patches. http://gnuradio.org/cgit/jblum.git/commit/?h=freebsd_tweaks&id=ca3868256079060993ebb643e34b39c558052ce0 1) make qwt find script better. Its fixes the need to manually specify -DQWT_INCLUDE_DIRS 2) Use CLOCK_GETTIME and not MACH_ABSOLUTE_TIME. Question: Did gr-qtgui compile for you without this change? In other words, does your OS have mach kernel headers? -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build gnuradio on FreeBSD
Yeah, I asked about that earlier, for some reason qwt is hard coded to /usr/include in the configure script. It really should just use the system path and not check just one predefined path, this also is a problem on Gentoo and any other OS that uses "/usr/local/" instead of "/usr/". What the configure script should do is make two C programs: #include < qwt/qwt_math.h > and #include < qwt5/qwt_math.h > then see which compiles to find the qwt include folder name, or just not check and assume the first as that is what the code expects and most systems do anyway. Checking breaks more systems than it helps at this point, if anyone uses qwt5 directory they should just change it themselves. On Wed, Jan 11, 2012 at 9:55 AM, LRK wrote: > > I do not find anything in the README about qt4 or qwt but they seem > to be required for gr-qtgui. > > I used portinstall to install py27-qt4 and several hours and 57 packages > later, cmake could find qt4. > > Then I installed py27-pyqwt and it also installed qwt-5.2.2. Cmake > still would not find qwt. (QWT_FOUND = FALSE). > > I finally tried adding the QWT_INCLUDE_DIRS line below and cmake now > finds qwt and shows gr-qtgui to be built. Trying that next. > >cmake \ > -DCMAKE_INSTALL_PREFIX=$GR_PREFIX \ > -DQWT_INCLUDE_DIRS=/usr/local/include/qwt \ > ../ > > > -- > LRK > gr-user . ovillatx.sytes.net > > ___ > 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
Re: [Discuss-gnuradio] cmake build of Gnu Radio failing this morning
On 11/08/2011 04:24 AM, Marcus D. Leech wrote: > Fedora 12, 32-bit: > > [ 0%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter.cc.o > [ 0%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter_msgq.cc.o > [ 0%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o > [ 0%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_unv.cc.o > [ 0%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt.cc.o > [ 1%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_io.cc.o > [ 1%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o > [ 1%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_serialize.cc.o > [ 1%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/realtime.cc.o > [ 1%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/sys_pri.cc.o > [ 1%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/thread_body_wrapper.cc.o > [ 2%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/thread_group.cc.o > Linking CXX shared library libgruel.so > make[2]: *** [gruel/src/lib/libgruel.so.0.0.0] Error 1 > make[1]: *** [gruel/src/lib/CMakeFiles/gruel.dir/all] Error 2 > > This is from a clean source tree, with -DENABLE_VOLK=NO on the cmake > > I dont see an error. Why do you think its volk? -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build of Gnu Radio failing this morning
> > Fedora 12, 32-bit: > > [ 0%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter.cc.o > [ 0%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter_msgq.cc.o > [ 0%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o > [ 0%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_unv.cc.o > [ 0%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt.cc.o > [ 1%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_io.cc.o > [ 1%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o > [ 1%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_serialize.cc.o > [ 1%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/realtime.cc.o > [ 1%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/sys_pri.cc.o > [ 1%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/thread_body_wrapper.cc.o > [ 2%] Building CXX object > gruel/src/lib/CMakeFiles/gruel.dir/thread_group.cc.o > Linking CXX shared library libgruel.so > make[2]: *** [gruel/src/lib/libgruel.so.0.0.0] Error 1 > make[1]: *** [gruel/src/lib/CMakeFiles/gruel.dir/all] Error 2 > > This is from a clean source tree, with -DENABLE_VOLK=NO on the cmake > > > And another piece of data--an autotools build worked just fine (with -disable-volk) -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
On 09/11/2011 10:36 PM, Ben Reynwar wrote: > Undefined symbols: > "_CloseComponent" Try this one-liner: http://pastebin.com/M2Pz7km1 Based on this issue: https://trac.macports.org/ticket/18718 -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
On Sun, Sep 11, 2011 at 11:09 AM, Josh Blum wrote: > > > On 09/11/2011 04:37 AM, Michael Dickens wrote: >> Unless Josh changed something recently, the cmake build (with volk >> disabled) worked for me under 10.6.8, XCode 3.2.3, 64-bit. It looks >> like Ben is doing this testing on 10.5.8, XCode 3.1.4 -- which by >> default will use 32-bit for either PPC or Intel compiling, and, >> really, getting 64-bit was somewhat of a challenge until 10.6. A >> "fat" or "universal" build o 10.5 meant 32-bit PPC and Intel merged >> into a single file. IIRC, gcc under 10.5.8 could be coerced into >> doing 64-bit, but doing so was much more reliable using Apple's >> interface. All of that changed with 10.6, since 64-bit was the >> default for any capable processor (and, all processors were Intel, >> and mostly legacy ones were 32-bit only), and "universal" meant (and >> still means) both 32- and 64-bit Intel compiling (merged). Given >> that "we" designed the GR autotools build to work on OSX with both >> 32- and 64-bit compiling, starting early in 10.5 days, I'm glad that >> that build still works correctly. >> >> With the above I mind, it would probably help to know from Ben what >> "arch" and "uname -a" return. Looking at Josh's pastebin change, I >> would bet that CMAKE_SYSTEM_PROCESSOR is "i386" (it is for all Intel >> OSX builds, as far as I know). But, under 10.5, >> CMAKE_SYSTEM_PROCESSOR should probably be "i386", not "x86_64" -- >> but, it really depends on what Ben's system is / provides. - MLD >> >> > > This is only an issue w/ gr-filter where we try to perform arch > detection. The way volk is doing it should always be ok :-) > > I made a branch detect_x86_type on jblum.git, where I try to detect the > compiler's bit width in filter. I think its a lot more robust: > > http://gnuradio.org/cgit/jblum.git/log/?h=detect_x86_type > > -josh > Yep, that fixed the problem. In case anyone wants to continuing playing "get the cmake build working on an obsolete macbook" game, here is the next error I get. I should emphasize that I don't need to get this working, so it's only of importance if you think that getting the cmake build working on a 4 year old macbook is a worthwhile goal :). [ 74%] Building CXX object gr-audio/lib/CMakeFiles/gnuradio-audio.dir/osx/audio_osx_sink.cc.o Linking CXX shared library libgnuradio-audio.dylib ld warning: duplicate dylib /usr/local/lib/libboost_date_time-mt.dylib ld warning: duplicate dylib /usr/local/lib/libboost_program_options-mt.dylib ld warning: duplicate dylib /usr/local/lib/libboost_filesystem-mt.dylib ld warning: duplicate dylib /usr/local/lib/libboost_system-mt.dylib ld warning: duplicate dylib /usr/local/lib/libboost_thread-mt.dylib Undefined symbols: "_CloseComponent", referenced from: audio_osx_source::~audio_osx_source()in audio_osx_source.cc.o audio_osx_source::~audio_osx_source()in audio_osx_source.cc.o audio_osx_source::~audio_osx_source()in audio_osx_source.cc.o audio_osx_sink::~audio_osx_sink()in audio_osx_sink.cc.o audio_osx_sink::~audio_osx_sink()in audio_osx_sink.cc.o audio_osx_sink::~audio_osx_sink()in audio_osx_sink.cc.o "_OpenAComponent", referenced from: audio_osx_source::audio_osx_source(int, std::basic_string, std::allocator >, bool, int, int)in audio_osx_source.cc.o audio_osx_source::audio_osx_source(int, std::basic_string, std::allocator >, bool, int, int)in audio_osx_source.cc.o audio_osx_sink::audio_osx_sink(int, std::basic_string, std::allocator >, bool, int, int)in audio_osx_sink.cc.o audio_osx_sink::audio_osx_sink(int, std::basic_string, std::allocator >, bool, int, int)in audio_osx_sink.cc.o "_FindNextComponent", referenced from: audio_osx_source::audio_osx_source(int, std::basic_string, std::allocator >, bool, int, int)in audio_osx_source.cc.o audio_osx_source::audio_osx_source(int, std::basic_string, std::allocator >, bool, int, int)in audio_osx_source.cc.o audio_osx_sink::audio_osx_sink(int, std::basic_string, std::allocator >, bool, int, int)in audio_osx_sink.cc.o audio_osx_sink::audio_osx_sink(int, std::basic_string, std::allocator >, bool, int, int)in audio_osx_sink.cc.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [gr-audio/lib/libgnuradio-audio.3.x.x.dylib] Error 1 make[1]: *** [gr-audio/lib/CMakeFiles/gnuradio-audio.dir/all] Error 2 make: *** [all] Error 2 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
On 09/11/2011 04:37 AM, Michael Dickens wrote: > Unless Josh changed something recently, the cmake build (with volk > disabled) worked for me under 10.6.8, XCode 3.2.3, 64-bit. It looks > like Ben is doing this testing on 10.5.8, XCode 3.1.4 -- which by > default will use 32-bit for either PPC or Intel compiling, and, > really, getting 64-bit was somewhat of a challenge until 10.6. A > "fat" or "universal" build o 10.5 meant 32-bit PPC and Intel merged > into a single file. IIRC, gcc under 10.5.8 could be coerced into > doing 64-bit, but doing so was much more reliable using Apple's > interface. All of that changed with 10.6, since 64-bit was the > default for any capable processor (and, all processors were Intel, > and mostly legacy ones were 32-bit only), and "universal" meant (and > still means) both 32- and 64-bit Intel compiling (merged). Given > that "we" designed the GR autotools build to work on OSX with both > 32- and 64-bit compiling, starting early in 10.5 days, I'm glad that > that build still works correctly. > > With the above I mind, it would probably help to know from Ben what > "arch" and "uname -a" return. Looking at Josh's pastebin change, I > would bet that CMAKE_SYSTEM_PROCESSOR is "i386" (it is for all Intel > OSX builds, as far as I know). But, under 10.5, > CMAKE_SYSTEM_PROCESSOR should probably be "i386", not "x86_64" -- > but, it really depends on what Ben's system is / provides. - MLD > > This is only an issue w/ gr-filter where we try to perform arch detection. The way volk is doing it should always be ok :-) I made a branch detect_x86_type on jblum.git, where I try to detect the compiler's bit width in filter. I think its a lot more robust: http://gnuradio.org/cgit/jblum.git/log/?h=detect_x86_type -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
Unless Josh changed something recently, the cmake build (with volk disabled) worked for me under 10.6.8, XCode 3.2.3, 64-bit. It looks like Ben is doing this testing on 10.5.8, XCode 3.1.4 -- which by default will use 32-bit for either PPC or Intel compiling, and, really, getting 64-bit was somewhat of a challenge until 10.6. A "fat" or "universal" build o 10.5 meant 32-bit PPC and Intel merged into a single file. IIRC, gcc under 10.5.8 could be coerced into doing 64-bit, but doing so was much more reliable using Apple's interface. All of that changed with 10.6, since 64-bit was the default for any capable processor (and, all processors were Intel, and mostly legacy ones were 32-bit only), and "universal" meant (and still means) both 32- and 64-bit Intel compiling (merged). Given that "we" designed the GR autotools build to work on OSX with both 32- and 64-bit compiling, starting early in 10.5 days, I'm glad that that build still works correctly. With the above I mind, it would probably help to know from Ben what "arch" and "uname -a" return. Looking at Josh's pastebin change, I would bet that CMAKE_SYSTEM_PROCESSOR is "i386" (it is for all Intel OSX builds, as far as I know). But, under 10.5, CMAKE_SYSTEM_PROCESSOR should probably be "i386", not "x86_64" -- but, it really depends on what Ben's system is / provides. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
> float_dotprod_sse64.S:84:bad register name `%rsi' > float_dotprod_sse64.S:87:bad register name `%rax' > float_dotprod_sse64.S:96:bad register name `%rdx' > float_dotprod_sse64.S:101:bad register name `%rsi)' > float_dotprod_sse64.S:103:bad register name `%rsi)' > float_dotprod_sse64.S:111:bad register name `%rdi)' > float_dotprod_sse64.S:113:bad register name `%rsi)' > float_dotprod_sse64.S:115:bad register name `%rdi)' > float_dotprod_sse64.S:117:bad register name `%rsi)' > float_dotprod_sse64.S:119:bad register name `%rdi)' > float_dotprod_sse64.S:121:bad register name `%rsi)' > float_dotprod_sse64.S:123:bad register name `%rdi)' > float_dotprod_sse64.S:125:bad register name `%rsi)' > float_dotprod_sse64.S:127:bad register name `%rdi' > float_dotprod_sse64.S:128:bad register name `%rsi' > float_dotprod_sse64.S:129:bad register name `%rdx' > float_dotprod_sse64.S:158:suffix or operands invalid for `ret' > make[2]: *** > [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/float_dotprod_sse64.S.o] > Error 1 > make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2 > make: *** [all] Error 2 > Is the build correctly detecting your machine arch (you have a x86-64)? If so, gcc may also need to build those sources w/ -m64, here is my best guess for a correction: http://pastebin.com/gNrnG8kE -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
I got everything working in the end by upgrading python to 2.7 and by using the standard autotools installation with volk disabled (I didn't try in with volk enabled based on your advice). However, for the sake of completeness, here is the error that prevented me from using cmake with python 2.7 installed. [ 9%] Building C object gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/sse_debug.c.o [ 9%] Building C object gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/float_dotprod_sse64.S.o float_dotprod_sse64.S:66:bad register name `%rdx' float_dotprod_sse64.S:76:bad register name `%rax' float_dotprod_sse64.S:81:bad register name `%rsi)' float_dotprod_sse64.S:82:bad register name `%rdi)' float_dotprod_sse64.S:83:bad register name `%rdi' float_dotprod_sse64.S:84:bad register name `%rsi' float_dotprod_sse64.S:87:bad register name `%rax' float_dotprod_sse64.S:96:bad register name `%rdx' float_dotprod_sse64.S:101:bad register name `%rsi)' float_dotprod_sse64.S:103:bad register name `%rsi)' float_dotprod_sse64.S:111:bad register name `%rdi)' float_dotprod_sse64.S:113:bad register name `%rsi)' float_dotprod_sse64.S:115:bad register name `%rdi)' float_dotprod_sse64.S:117:bad register name `%rsi)' float_dotprod_sse64.S:119:bad register name `%rdi)' float_dotprod_sse64.S:121:bad register name `%rsi)' float_dotprod_sse64.S:123:bad register name `%rdi)' float_dotprod_sse64.S:125:bad register name `%rsi)' float_dotprod_sse64.S:127:bad register name `%rdi' float_dotprod_sse64.S:128:bad register name `%rsi' float_dotprod_sse64.S:129:bad register name `%rdx' float_dotprod_sse64.S:158:suffix or operands invalid for `ret' make[2]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/float_dotprod_sse64.S.o] Error 1 make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2 make: *** [all] Error 2 On Sat, Sep 10, 2011 at 7:40 PM, Michael Dickens wrote: >> Use --disable-volk on the configure command line to disable it, and >> everything else should work. > > Right. CMake. Use what Josh said: -DENABLE_VOLK=OFF on the cmake command > line. I'm still in GNU autotools mode. - MLD > > > ___ > 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
Re: [Discuss-gnuradio] cmake build
> Use --disable-volk on the configure command line to disable it, and > everything else should work. Right. CMake. Use what Josh said: -DENABLE_VOLK=OFF on the cmake command line. I'm still in GNU autotools mode. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
> The problem I'm running into appears to be caused by the installed > version of python being 2.5. Cmake requests a version of 2.5 or later > so it should be okay, however I get the following error. > > Serf:gnuradio-build ben$ make > [ 0%] Generating ../include/volk/volk.h, volk.c, volk_init.h, > ../include/volk/volk_typedefs.h, ../include/volk/volk_cpu.h, > volk_cpu.c, ../include/volk/volk_config_fixed.h, > volk_environment_init.c, volk_environment_init.h, volk_machines.h, > volk_machines.c, volk_machine_generic.c, volk_machine_sse2_only.c, > volk_machine_sse2_32.c, volk_machine_sse3_32.c, > volk_machine_ssse3_32.c > Unknown option: -B > usage: > /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python > [option] ... [-c cmd | -m mod | file | -] [arg] ... > Try `python -h' for more information. > make[2]: *** [volk/include/volk/volk.h] Error 2 > make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 > make: *** [all] Error 2 > > A google suggests that the -B option for python was added in 2.6. > I'll install a newer version of python and see if I have more luck. > The -B tells python not to generate .pyc files (to keep junk from being generated in tree). I didnt realize it was for 2.6 and up. For now, you can harmlessly remove it, or alternatively, disable volk -DENABLE_VOLK=ON/OFF -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
Hi Ben - I believe that Volk (in general, not just the Python version) doesn't play nicely with OSX (any version) yet. Use --disable-volk on the configure command line to disable it, and everything else should work. - MLD On Sep 10, 2011, at 5:24 PM, Ben Reynwar wrote: > Just tested the cmake install on OS X 10.5.8, XCode 3.1.4, Homebrew > for dependencies. Homebrew is not quite up to scratch for the > dependencies since it's missing pyqwk and pygtk, and qt is there but > the install script failed for me. Anyway there's enough working for > gnuradio-core to install but not gnuradio-companion. > > The problem I'm running into appears to be caused by the installed > version of python being 2.5. Cmake requests a version of 2.5 or later > so it should be okay, however I get the following error. > > Serf:gnuradio-build ben$ make > [ 0%] Generating ../include/volk/volk.h, volk.c, volk_init.h, > ../include/volk/volk_typedefs.h, ../include/volk/volk_cpu.h, > volk_cpu.c, ../include/volk/volk_config_fixed.h, > volk_environment_init.c, volk_environment_init.h, volk_machines.h, > volk_machines.c, volk_machine_generic.c, volk_machine_sse2_only.c, > volk_machine_sse2_32.c, volk_machine_sse3_32.c, > volk_machine_ssse3_32.c > Unknown option: -B > usage: > /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python > [option] ... [-c cmd | -m mod | file | -] [arg] ... > Try `python -h' for more information. > make[2]: *** [volk/include/volk/volk.h] Error 2 > make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 > make: *** [all] Error 2 > > A google suggests that the -B option for python was added in 2.6. > I'll install a newer version of python and see if I have more luck. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
Just tested the cmake install on OS X 10.5.8, XCode 3.1.4, Homebrew for dependencies. Homebrew is not quite up to scratch for the dependencies since it's missing pyqwk and pygtk, and qt is there but the install script failed for me. Anyway there's enough working for gnuradio-core to install but not gnuradio-companion. The problem I'm running into appears to be caused by the installed version of python being 2.5. Cmake requests a version of 2.5 or later so it should be okay, however I get the following error. Serf:gnuradio-build ben$ make [ 0%] Generating ../include/volk/volk.h, volk.c, volk_init.h, ../include/volk/volk_typedefs.h, ../include/volk/volk_cpu.h, volk_cpu.c, ../include/volk/volk_config_fixed.h, volk_environment_init.c, volk_environment_init.h, volk_machines.h, volk_machines.c, volk_machine_generic.c, volk_machine_sse2_only.c, volk_machine_sse2_32.c, volk_machine_sse3_32.c, volk_machine_ssse3_32.c Unknown option: -B usage: /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. make[2]: *** [volk/include/volk/volk.h] Error 2 make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 make: *** [all] Error 2 A google suggests that the -B option for python was added in 2.6. I'll install a newer version of python and see if I have more luck. Cheers, Ben On Thu, Aug 18, 2011 at 6:07 PM, Tom Rondeau wrote: > And another thing... > > We are looking at possibly moving from autotools to cmake. In many > ways, cmake looks like it will simply many of our build issues and > actually solve others. Josh Blum has been doing outstanding work in > converting the GNU Radio build system over to using cmake, and we > really need testers to chip away at any of the bugs. Specifically, we > have tested it on some modern OSes, but we want ot make sure that it > covers most (if not all) of our customer base (I'm sorry, but if it > come down to it, I'm willing to let the VAX users go...). > > Find the instructions to start working on it here: > http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork > > Please post both positive and negative experiences so that we know not > only what to fix, but it will also let us know what systems are > working. > > Thanks! > Tom > > ___ > 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
Re: [Discuss-gnuradio] cmake build
On Fri, Aug 26, 2011 at 10:12:16AM -0700, Josh Blum wrote: > > 3) Suggestion: automatically set the test systems by use of GLOBs. I > > guess if *all* lib/qa_*.cc and python/qa_*.py are automatically added to > > the tests portfolio, this would be fine with most developers 99% of the > > time. I still think the 1% are brilliant enough to adapt the build > > system to their needs (instead of the other way round). > > > > So here is an example of globbing w/ gr-digital: > http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/CMakeLists.txt?h=next#n54 > > And here is the "manual" way of doing it in gr-howto > http://gnuradio.org/cgit/jblum.git/tree/gr-howto-write-a-block-cmake/python/CMakeLists.txt?h=next#n37 > > My thoughts where that the gr-howto is to help learn by example, and > that the code would be easier to understand the "manual" way. > > Thoughts? A compromise might be to put more comments and annotations into the CMakeLists.txt, e.g. to explain how things would be done manually. With globs, there is less understanding of the build systems, but getting started is also easier--it would make the learning curve nicer for newbies. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpv8Np0ny5Xx.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
> > 3) Suggestion: automatically set the test systems by use of GLOBs. I > guess if *all* lib/qa_*.cc and python/qa_*.py are automatically added to > the tests portfolio, this would be fine with most developers 99% of the > time. I still think the 1% are brilliant enough to adapt the build > system to their needs (instead of the other way round). > So here is an example of globbing w/ gr-digital: http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/CMakeLists.txt?h=next#n54 And here is the "manual" way of doing it in gr-howto http://gnuradio.org/cgit/jblum.git/tree/gr-howto-write-a-block-cmake/python/CMakeLists.txt?h=next#n37 My thoughts where that the gr-howto is to help learn by example, and that the code would be easier to understand the "manual" way. Thoughts? -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
> We are looking at possibly moving from autotools to cmake. In many > ways, cmake looks like it will simply many of our build issues and > actually solve others. Josh Blum has been doing outstanding work in > converting the GNU Radio build system over to using cmake, and we > really need testers to chip away at any of the bugs. Specifically, we > have tested it on some modern OSes, but we want ot make sure that it > covers most (if not all) of our customer base (I'm sorry, but if it > come down to it, I'm willing to let the VAX users go...). > > Find the instructions to start working on it here: > http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork > > Please post both positive and negative experiences so that we know not > only what to fix, but it will also let us know what systems are > working. I've now found the time to also check out gr-howto-...-cmake. Here's some comments: 1) Once again, the build process feels faster and cleaner. 2) One feature I miss is the build-variable 'modname'. Wouldn't such a variable make things easier? I'm guessing for most people, gr-howto is a template for out-of-tree modules, so most of the default settings would be OK. In this case, a variable 'MODNAME' would possibly make the CMakeLists.txt even simpler, and give the developer less options (which he will never need). Example: the name 'howto' pops up very often in CMake files. Imagine someone starts building a module, then renames it during the process (say, from howto to how2). Most developers would like all libraries, .so-files, modules etc. to be renamed to e.g. gnuradio-how2.so etc. However, with the given structure, a lot of manual renaming is necessary in CMakeLists.txt's. (Of course, renaming files will have to be done by hand). gr_modtool.py also uses this, by the way. 3) Suggestion: automatically set the test systems by use of GLOBs. I guess if *all* lib/qa_*.cc and python/qa_*.py are automatically added to the tests portfolio, this would be fine with most developers 99% of the time. I still think the 1% are brilliant enough to adapt the build system to their needs (instead of the other way round). My couple of €-cents... MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpBhxBHevqmw.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
The DYLD_LIBRARY_PATH is not being set in the shell script when using CMake. It is being set when using autotools (in the run_tests.sh file). Maybe this makes a difference? - MLD > Take a look at > /opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh > and see if any environment variables are suspicious. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
On Aug 19, 2011, at 3:27 PM, Josh Blum wrote: >> Command: "/bin/sh" >> "/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh" >> Directory: >> /opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr >> "qa_agc" start time: Aug 19 09:41 EDT >> Output: >> -- >> Fatal Python error: PyThreadState_Get: no current thread >> /opt/GNURadio/git_new/builds/jb_next_cmake/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh: >> line 8: 3157 Abort trap /opt/local/bin/python2.6 >> /opt/GNURadio/git_new/gnuradio-core/src/python/gnuradio/gr/qa_agc.py > > Thats a very strange error. I have tested this on my macmini and havent > seen the same. Do you see errors when running the tests under autotools > on the next branch? No, the autotools variation does fine once you fix the errors in "gruel/src/include/gruel/Makefile.am" (seems like an extra "<<< HEAD" got in there) -- I mean, it still errors out doing the socket test, but otherwise the Python tests run OK (and pass). > Take a look at > /opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh > and see if any environment variables are suspicious. Hmmm ... those look OK overall. If I have time, I'll look at this over the weekend -- or, maybe you'll figure it out before then :) - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
> Command: "/bin/sh" > "/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh" > Directory: > /opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr > "qa_agc" start time: Aug 19 09:41 EDT > Output: > -- > Fatal Python error: PyThreadState_Get: no current thread > /opt/GNURadio/git_new/builds/jb_next_cmake/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh: > line 8: 3157 Abort trap /opt/local/bin/python2.6 > /opt/GNURadio/git_new/gnuradio-core/src/python/gnuradio/gr/qa_agc.py Thats a very strange error. I have tested this on my macmini and havent seen the same. Do you see errors when running the tests under autotools on the next branch? Take a look at /opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh and see if any environment variables are suspicious. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
On Aug 19, 2011, at 11:24 AM, Josh Blum wrote: > OK, make sure that if this was checked out from an old repository that > you git cleaned -dfx to remove any old in-tree generated headers. That > could have caused some of the problems you are seeing. > > Can you send me /Testing/Temporary/LastTest.log > > Alternatively, you can usually run > /component/python/.sh manually to get the verbose. This was a fresh checkout, and all I had tried to do was build Volk (which failed) -- so I don't think cleaning will help. I checked out he LastTest.log file, and here's an example (all of the errors are like this one): Command: "/bin/sh" "/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh" Directory: /opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr "qa_agc" start time: Aug 19 09:41 EDT Output: -- Fatal Python error: PyThreadState_Get: no current thread /opt/GNURadio/git_new/builds/jb_next_cmake/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh: line 8: 3157 Abort trap /opt/local/bin/python2.6 /opt/GNURadio/git_new/gnuradio-core/src/python/gnuradio/gr/qa_agc.py Test time = 0.09 sec -- Test Failed. "qa_agc" end time: Aug 19 09:41 EDT "qa_agc" time elapsed: 00:00:00 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
On 08/19/2011 08:48 AM, Martin Braun wrote: > On Fri, Aug 19, 2011 at 08:42:52AM -0700, Josh Blum wrote: >>> [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o] Error 1 >>> make[1]: *** [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/all] Error 2 >>> >>> I believe this should be caught by the configuration process, not >>> during the build (...?) >>> >> >> Does uhd/usrp/multi_usrp.hpp actually exist on the machine? And did >> gnuradio (current master) build w/ this version of uhd? There may have >> been an issue w/ an older uhd.pc file. > > Hm... sorry, I didn't check. I cleaned out all UHD and re-installed, > after that the build worked like a charm. > It probably didn't, but still, shouldn't that be caught by cmake's > configuration step? > Yes. It looks like I am not imposing a version check on uhd, which I should be. So it probably accepted the older pc file. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
On Fri, Aug 19, 2011 at 08:42:52AM -0700, Josh Blum wrote: > > [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o] Error 1 > > make[1]: *** [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/all] Error 2 > > > > I believe this should be caught by the configuration process, not > > during the build (...?) > > > > Does uhd/usrp/multi_usrp.hpp actually exist on the machine? And did > gnuradio (current master) build w/ this version of uhd? There may have > been an issue w/ an older uhd.pc file. Hm... sorry, I didn't check. I cleaned out all UHD and re-installed, after that the build worked like a charm. It probably didn't, but still, shouldn't that be caught by cmake's configuration step? > > * I noticed radar-mono and sounder are missing. If that was done on > > purpose, then good riddance. While they're interesting demos, they're > > not really useful and I always disabled them. > > > > I believe those components will be removed in the near future. Thank god. They should move to CGRAN, though. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpjr3rLA41yf.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
> I like it! > ...some more verbose comments: > > * All of my machines are pretty standard (all Ubuntu, 32 and 64 bit > flavours, versions 11.04 and 10.10). It works on both (with some minor > issues). > > * One of the machines had an old UHD version, which manages to crash the > build: > > [ 88%] Building CXX object > gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o > In file included from > /home/braun/src/gnuradio-cmake/gr-uhd/lib/gr_uhd_usrp_source.cc:22: > /home/braun/src/gnuradio-cmake/gr-uhd/include/gr_uhd_usrp_source.h:27: > fatal error: uhd/usrp/multi_usrp.hpp: No such file or directory > compilation terminated. > make[2]: *** > [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o] Error 1 > make[1]: *** [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/all] Error 2 > > I believe this should be caught by the configuration process, not > during the build (...?) > Does uhd/usrp/multi_usrp.hpp actually exist on the machine? And did gnuradio (current master) build w/ this version of uhd? There may have been an issue w/ an older uhd.pc file. > * I didn't time it, but is the build time much faster? Even if this is > only subjective, it's an improvement. > Ive noticed this too. :-) > * The way the CMakeLists.txt look, this system seems much easier to > configure. Thumbs up! (Even though it's actually longer :) > The cause of this may be that the job performed by makefile.swig.gen*, runtests.in*, *.m4, *.am files is actually combined into the cmakelists. Same functionality, less files. > * One of the tests failed: > > 99% tests passed, 1 tests failed out of 83 > > Total Test time (real) = 71.21 sec > > The following tests FAILED: > 69 - qa_costas_loop_cc (Failed) > Errors while running CTest > make: *** [test] Error 8 > > This is a known issue w/ gr-digital. Tom has a fix in his digital branch > * I noticed radar-mono and sounder are missing. If that was done on > purpose, then good riddance. While they're interesting demos, they're > not really useful and I always disabled them. > I believe those components will be removed in the near future. Thanks for testing! -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
> Test project /opt/GNURadio/git_new/builds/jb_next_cmake > Start 1: gruel-test > 1/82 Test #1: gruel-test ... Passed3.02 sec > Start 2: qa_pmt > 2/82 Test #2: qa_pmt ...***Failed1.26 sec > Start 3: gr-core-reed-solomon-test > 3/82 Test #3: gr-core-reed-solomon-test Passed0.09 sec > Start 4: gr-core-test-all > 4/82 Test #4: gr-core-test-all . Passed 11.53 sec > Start 5: qa_add_and_friends > 5/82 Test #5: qa_add_and_friends ...***Failed0.45 sec > Start 6: qa_add_v_and_friends > [ all of the rest of the tests fail; > I get lots of pop-ups telling me that Python unexpectedly quit ] > 5% tests passed, 78 tests failed out of 82 > > Total Test time (real) = 29.37 sec > OK, make sure that if this was checked out from an old repository that you git cleaned -dfx to remove any old in-tree generated headers. That could have caused some of the problems you are seeing. Can you send me /Testing/Temporary/LastTest.log Alternatively, you can usually run /component/python/.sh manually to get the verbose. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
On Thu, Aug 18, 2011 at 09:07:15PM -0400, Tom Rondeau wrote: > We are looking at possibly moving from autotools to cmake. In many > ways, cmake looks like it will simply many of our build issues and > actually solve others. Josh Blum has been doing outstanding work in > converting the GNU Radio build system over to using cmake, and we > really need testers to chip away at any of the bugs. Specifically, we > have tested it on some modern OSes, but we want ot make sure that it > covers most (if not all) of our customer base (I'm sorry, but if it > come down to it, I'm willing to let the VAX users go...). > > Find the instructions to start working on it here: > http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork > > Please post both positive and negative experiences so that we know not > only what to fix, but it will also let us know what systems are > working. I like it! ...some more verbose comments: * All of my machines are pretty standard (all Ubuntu, 32 and 64 bit flavours, versions 11.04 and 10.10). It works on both (with some minor issues). * One of the machines had an old UHD version, which manages to crash the build: [ 88%] Building CXX object gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o In file included from /home/braun/src/gnuradio-cmake/gr-uhd/lib/gr_uhd_usrp_source.cc:22: /home/braun/src/gnuradio-cmake/gr-uhd/include/gr_uhd_usrp_source.h:27: fatal error: uhd/usrp/multi_usrp.hpp: No such file or directory compilation terminated. make[2]: *** [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o] Error 1 make[1]: *** [gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/all] Error 2 I believe this should be caught by the configuration process, not during the build (...?) * I didn't time it, but is the build time much faster? Even if this is only subjective, it's an improvement. * The way the CMakeLists.txt look, this system seems much easier to configure. Thumbs up! (Even though it's actually longer :) * One of the tests failed: 99% tests passed, 1 tests failed out of 83 Total Test time (real) = 71.21 sec The following tests FAILED: 69 - qa_costas_loop_cc (Failed) Errors while running CTest make: *** [test] Error 8 * I noticed radar-mono and sounder are missing. If that was done on purpose, then good riddance. While they're interesting demos, they're not really useful and I always disabled them. I hope this transition comes soon! MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgphrl2u3G1dB.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
Testing on OSX 10.6.8, XCode 3.2.3 (gcc 4.2.1 with Apple tweaks), MacPorts 2.0.0 for all other dependencies. It looks like that "configure' and 'build' CMake logic is pretty good. I'd guess there's an issue with how 'Python' is called during the 'test' stage. >From the top-level git directory, after pulling Josh's next branch and >switching to it: % mkdir -p builds/cmake_next % cd builds/cmake_next % cmake ../.. [ succeeds, but finds Python 2.7 instead of 2.6; "which python" -> python 2.6 installed by MacPorts ] % make [ fails at Volk, which is not a surprise ] % cmake ../.. -DPYTHON_EXECUTABLE=/opt/local/bin/python2.6 -DENABLE_VOLK=off [ finds correct Python now; succeeds, disables gr-qtgui, which is not a surprise ] % make [ succeeds ] % make test Running tests... Test project /opt/GNURadio/git_new/builds/jb_next_cmake Start 1: gruel-test 1/82 Test #1: gruel-test ... Passed3.02 sec Start 2: qa_pmt 2/82 Test #2: qa_pmt ...***Failed1.26 sec Start 3: gr-core-reed-solomon-test 3/82 Test #3: gr-core-reed-solomon-test Passed0.09 sec Start 4: gr-core-test-all 4/82 Test #4: gr-core-test-all . Passed 11.53 sec Start 5: qa_add_and_friends 5/82 Test #5: qa_add_and_friends ...***Failed0.45 sec Start 6: qa_add_v_and_friends [ all of the rest of the tests fail; I get lots of pop-ups telling me that Python unexpectedly quit ] 5% tests passed, 78 tests failed out of 82 Total Test time (real) = 29.37 sec ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
On Thu, Aug 18, 2011 at 09:07:15PM -0400, Tom Rondeau wrote: > And another thing... > > [...] > > Find the instructions to start working on it here: > http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork Seems like the 'site is down again. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgph9jUgCLCmC.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
