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
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-gnur
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 outp
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]
> -- Performi
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 - Suc
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 2
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.2gi
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
> l
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/l
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 s
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 path
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 py
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 als
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 conf
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
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/
>
> 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%]
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 objec
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-gnurad
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
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 o
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 som
> 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 re
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 i
> 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
> 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.
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
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 n
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 st
>
> 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
> syst
> 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 t
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 se
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
>> Ou
> 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:
> ---
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.
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
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
> 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:
>
> 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
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 bui
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
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)
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 ne
43 matches
Mail list logo
