On 07/10/2024 01:11, Elmore Family wrote:
Chris,
Here is what I have after cmake:
-- ##
-- # Gnuradio enabled components
-- ##
-- * testing-support
-- * post-install
-- * doxygen
-- *
On 09/06/2021 00:28, Ron Economos wrote:
It's not looking for sdl2, it's looking for sdl1.2.
If you're using a version of CMake greater than 3.17, you can turn on
find_package debugging by adding the following to the cmake invocation:
-DCMAKE_FIND_DEBUG_MODE=1
This will give copious output a
gnuradio & cmake seem not to be able to detect the presence of sdl2
development files.
-- Configuring gr-video-sdl support...
-- Dependency SDL_FOUND = FALSE
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Disabling gr-video-sdl support.
-- Override with
On 05/02/2020 18:13, Sylvain Munaut wrote:
-- Checking for module 'gmp'
-- Found gmp, version 6.2.0
-- Could NOT find GMP (missing: GMPXX_LIBRARY GMP_INCLUDE_DIR)
Looks like mageia has split the c++ gmp bindings into libgmpxx-devel
make sure you have that installed.
We do have these install
On 05/02/2020 13:04, Sylvain Munaut wrote:
In gqrx build I am now hitting a fail to find gnuradio from this line in
CMakeLists.txt:
find_package(gnuradio REQUIRED COMPONENTS analog audio blocks digital
filter fft)
Are you sure you're using the latest gqrx code ?!? >
Here I have :
find_package(
On 04/02/2020 07:45, Sylvain Munaut wrote:
Without a .pc in gr-iqbal, gr-osmosdr (3.8 branch) will not build as it
can't find gr-iqbal.
I just had a look at gr-osmosdr-0.1.4.127-3.mga7.src.rpm and this is
not using the official code from the gr3.8 branch of
git.osmocom.org/gr-osmosdr
True, th
Hello,
Without a .pc in gr-iqbal, gr-osmosdr (3.8 branch) will not build as it
can't find gr-iqbal.
Likewise without a .pc in gr-osmosdr, gqrx will not build as it can't
find gr-osmosdr.
After creating .pc files for both the above all packages build and gqrx
runs fine.
I do not understan
On 08/12/2019 20:31, Sylvain Munaut wrote:
Hi,
I have just pushed updates to various osmocom repositories, updating
them to run on gnuradio 3.8.
--snip
Cheers,
Sylvain Munaut
PS: bcc'd package maintainer I thought of.
Hi,
Thanks for these updates, I maintain gnurad
On 03/11/2019 16:39, Gregory Ratcliff wrote:
Please keep us updated on your progress. This is something I was thinking to
do with aviation monitoring. Stream each channel at the airport, time shift to
fill in silence giving priority to the tower and approach streams.
Have you tried rtl-air
On 30/10/2019 00:09, Barry Jackson wrote:
On 27/10/2019 11:58, Marcus Müller wrote:
ah! I missed the part where you said you're not used to Python.
In Python, indentation is structure-defining, and the error message
sadly doesn't really give context, but it looks like the mos
On 27/10/2019 11:58, Marcus Müller wrote:
ah! I missed the part where you said you're not used to Python.
In Python, indentation is structure-defining, and the error message
sadly doesn't really give context, but it looks like the most probable
explanation is that the line you've inserted is no
On 24/10/2019 21:18, Håkon Vågsether wrote:
This error message also occurs in one of the GRC tests:
https://github.com/gnuradio/gnuradio/issues/2678
Best regards
Håkon Vågsether
Strange that there has been no response to your bug report since July.
Any other suggestions as to how to work a
Update:
Since last night I have re-created the patch and re-built and this time
the package built with:
self._docstring_extractor.finish()
# self._docstring_extractor.wait()
try:
utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
ppens if there's no 'options' block
pass
and things should work.
I honestly think we could improve the
hide_bokeh_gui_options_if_not_installed to handle None arguments and
use .get('options') instead of ['options']. Willing to pick up on that?
Best regards,
[baz@jackodesktop ~]$ gnuradio-companion
Traceback (most recent call last):
File "/usr/bin/gnuradio-companion", line 102, in
run_main()
File "/usr/bin/gnuradio-companion", line 95, in run_main
exit(main())
File "/usr/lib/python3.8/site-packages/gnuradio/grc/main.py", line
83, in ma
On 23/08/15 16:48, Barry Jackson wrote:
On 18/08/15 08:58, Philip Balister wrote:
Install blas, lapack or something that supplies the missing library.
Philip
On 08/18/2015 12:54 AM, Barry Jackson wrote:
Ping?
___
Discuss-gnuradio mailing list
On 18/08/15 08:58, Philip Balister wrote:
Install blas, lapack or something that supplies the missing library.
Philip
On 08/18/2015 12:54 AM, Barry Jackson wrote:
Ping?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https
Ping?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I checked without the %cmake macro so the --no-as-needed did not get
overridden and the error is the same:
Linking CXX shared library libgnuradio-wavelet-3.7.8.so
cd
/home/baz/BLD_Mga6_5/gnuradio/BUILD/gnuradio-3.7.8/build/gr-wavelet/lib
&& /usr/bin/cmake -E cmake_link_script
CMakeFiles/gnura
Thanks for your reply.
On 14/08/15 03:46, Chris Kuethe wrote:
$ dpkg -S /usr/lib/libcblas.*
libatlas-base-dev: /usr/lib/libcblas.a
libatlas-base-dev: /usr/lib/libcblas.so
libatlas3-base: /usr/lib/libcblas.so.3
libatlas3-base: /usr/lib/libcblas.so.3gf
$ dpkg -S /usr/lib/pkgconfig/*blas*pc
libatl
Trying to update our Mageia package to 3.7.8 using the release tarball,
we are hitting this:
[ 70%] Building CXX object
gr-wavelet/lib/CMakeFiles/gnuradio-wavelet.dir/wvps_ff_impl.cc.o
Linking CXX shared library libgnuradio-wavelet-3.7.8.so
/usr/bin/ld: cannot find -lcblas
collect2: error: ld
On 20/12/14 00:03, Martin Braun wrote:
On 12/19/2014 02:56 PM, John Meloche wrote:
[...]
forward. At a training course from Corgan Labs in the spring we were
warned that binaries will be phased out in favour of pybombs.
This leads me to a few questions:
1) Will the binaries be available and sup
Our gnuradio-3.7.1 package (from recent git) builds for x86_64 now pass
all tests on the Mageia build system. (qa_qtgui is excluded).
I found that we needed to export LD_LIBRARY_PATH=%{buildroot}%{_libdir}
in the build chroot for ctest to find the libs.
However I am seeing test failures on th
On 20/07/13 15:11, Tom Rondeau wrote:
On Thu, Jul 18, 2013 at 11:23 AM, Barry Jackson wrote:
On 18/07/13 15:19, Tom Rondeau wrote:
Do you know what version of ICE is installed on your system? GNU Radio
explicitly looks for version 3.4, so if you're using 3.5 it won't work
by def
On 18/07/13 15:19, Tom Rondeau wrote:
Do you know what version of ICE is installed on your system? GNU Radio
explicitly looks for version 3.4, so if you're using 3.5 it won't work
by default. I've tested and compiled against 3.5, though, so it's only
the cmake FindICE script that's the problem.
Anyone know how to resolve this build failure in Mageia ?
With no ice packages installed the build completes but without
gr-ctrlport enabled. With ice and ice-devel installed the output is as
below.
Our ice binaries install to /usr/bin and includes are in
/usr/include/Ice, usr/include/IceStorm
On 28/04/13 18:55, Tom Rondeau wrote:
That's very concerning about not finding libvolk.so. Make sure you
have, in the build directory, volk/lib/libvolk.so.0.0.0. If that's not
there, volk didn't build properly, which is necessary for the rest of
the QA tests that are failing.
Tom
Hi Tom,
The
On 25/04/13 15:26, Brian Stamper wrote:
On Thu, Apr 25, 2013 at 4:43 AM, Barry Jackson wrote:
On 24/04/13 22:09, Johnathan Corgan wrote:
[snip]
This was reported last January in the course of a thread related to
failures with Boost 1.5.2:
[snip]
Hi folks - all my tests in that thread were
On 24/04/13 22:09, Johnathan Corgan wrote:
On Wed, Apr 24, 2013 at 1:56 PM, Johnathan Corgan
wrote:
On Wed, Apr 24, 2013 at 10:50 AM, Brian Stamper wrote:
114: AssertionError: 39 != 31
114: AssertionError: 0.8 != 0.0 within 4 places
Now that's just being unreasonable :)
Actually, I recall
On 21/04/13 22:42, Stamper, Brian wrote:
Some additional information..
When I run make test I get the following failures:
22/192 Test #22: qa_fft_filter ***Failed 1.05 sec
85/192 Test #85: test_gr_filter ...***Failed 0.27 sec
91/192 Test #91: qa_fft_filter
On 25/01/13 17:04, Tom Rondeau wrote:
I'm test building all our other packages that use boost in the hope
that there are no breakages with 1.53b1 - if that happens then I may
have a case for pushing for an update.
Barry
Ok.
Tom
OK it's been a long haul but we now have boos
On 25/01/13 17:04, Tom Rondeau wrote:
On Fri, Jan 25, 2013 at 11:57 AM, Barry Jackson mailto:zen25...@zen.co.uk>> wrote:
The qtgui one that "fixed itself" still fails during the build, it
only passes when run manually.
During build? You mean if you run "make
On 25/01/13 16:29, Tom Rondeau wrote:
ldd test_all
[root@jackodesktop build]# cd volk/lib
[root@jackodesktop lib]# ldd test_all
linux-vdso.so.1 (0x7fff67096000)
libvolk.so.0.0.0 => not found
libboost_unit_test_framework.so.1.53.0 =>
/lib64/libboost_unit_test_fr
On 24/01/13 14:28, Tom Rondeau wrote:
Could you run 'ctest -V -R ' for these tests to see what they
are? I wouldn't worry too much about the ctcss and qtgui failures. My
OSX box has a problem with ctcss, too, though I've not gone to track it
down since it's not a heavily used blocks. The qtgui i
On 23/01/13 15:05, Tom Rondeau wrote:
On Wed, Jan 23, 2013 at 9:58 AM, Philip Balister mailto:phi...@balister.org>> wrote:
On 01/23/2013 09:45 AM, Tom Rondeau wrote:
> On Wed, Jan 23, 2013 at 5:42 AM, Barry Jackson
mailto:zen25...@zen.co.uk>> wrote:
>
I package gnuradio for Mageia and we are having problems with test
failures with 3.6.3 in our beta2 distro release.
(from git tag v3.6.3 since release tarball was from 3.6.4git)
We have boost-1.52 and the package builds, but fails 143 tests. Full
build system log is here:-
http://pkgsubmit.mag
It seems that 3.6.3 release tarball has been prepared from git tag
3.6.4git :\
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 04/06/12 05:27, Phil wrote:
Ok Marcus, it's Mageia 2, a fork off Mandriva.
I'm just about to push 3.6.0 to Cauldron. :)
Barry
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Could anyone please help me resolve this.
CMakeFiles/gnuradio-fcd.dir/hid/hid-libusb.c.o: In function
`hid_read_timeout':
/home/baz/BLD/CO9a/gnuradio/BUILD/gnuradio-3.5.3/gr-fcd/lib/hid/hid-libusb.c:990:
undefined reference to `clock_gettime'
collect2: ld returned 1 exit status
make[2]: *** [g
On 24/01/12 14:05, Tom Rondeau wrote:
On Tue, Jan 24, 2012 at 7:30 AM, Barry Jackson mailto:zen25...@zen.co.uk>> wrote:
I would like to use Cmake to build the 3.5.1 release, however the
tarball has no CMakeLists.txt files.
The project AFAICT seems generally to be Cmake enabl
I would like to use Cmake to build the 3.5.1 release, however the
tarball has no CMakeLists.txt files.
The project AFAICT seems generally to be Cmake enabled, is there a
reason for excluding the tarballs?
Any help would be appreciated.
___
Discuss-gn
41 matches
Mail list logo
