Re: [Discuss-gnuradio] Illegal CustomBuild for MSVC 18 (Gisle Vanem)
From:
Eugene Grayver
Subject:
Re: [Discuss-gnuradio] Illegal CustomBuild for MSVC 18 (Gisle Vanem)
Date:
Fri, 1 May 2015 12:06:36 -0700
I encountered the same problem. No
idea how to properly fix it, For now, I just did a global replace
in *.vcxproj for "" to nothing. That worked and I was able
to build everything.
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Re: Weird behavior of the correlate_and_sync
block (Richard Bell)
2. Re: gr-ais fails? (Martin Braun)
3. Generating Custom Packet Header (Richard Bell)
4. Re: Generating Custom Packet Header (Martin Braun)
5. Re: Swig and python import problem due to other out-of-tree
modules used in my out-of-tree module (Marcus M?ller)
6. Re: Generating Custom Packet Header (Richard Bell)
7. Re: QT GUI time sink (float) unnecessary memmove()? (Andy Walls)
8. Re: Weird behavior of the correlate_and_sync block (Andy Walls)
9. Re: gr-ais fails? (Kevin Reid)
10. Re: gr-ais fails? (Nick Foster)
11. Re: Swig and python import problem due to other out-of-tree
modules used in my out-of-tree module (Jeon)
12. Error in creating a block (Vishwanatha H G)
13. Re: Error in creating a block (Marcus M?ller)
14. Re: Swig and python import problem due to other out-of-tree
modules used in my out-of-tree module (Marcus M?ller)
15. Illegal CustomBuild for MSVC 18 (Gisle Vanem)
16. Copying OOT blocks to a different system (Murphy, John)
17. Re: Error in creating a block (Marcus M?ller)
18. Re: Copying OOT blocks to a different system (Marcus M?ller)
19. Re: gr-ais fails? (Ralph A. Schmid, dk5ras)
20. Re: gr-ais fails? (Ralph A. Schmid, dk5ras)
21. Re: Swig and python import problem due to other out-of-tree
modules used in my out-of-tree module (Jeon)
22. GNU Radio on Raspberry Pi Model 2?? (Mike Harpe)
23. Re: Swig and python import problem due to other out-of-tree
modules used in my out-of-tree module (Marcus M?ller)
Message: 1
Date: Mon, 30 Mar 2015 09:03:09 -0700
From: Richard Bell <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: Andy Walls <address@hidden>,
GNURadio Discussion
List
<address@hidden>
Subject: Re: [Discuss-gnuradio] Weird behavior of the
correlate_and_sync
block
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Andy,
I searched and found your archived discussions about this block. It
certainly seems like there were a lot of issues that you (and Nick Foster)
fixed. The github block you linked is in working order then? Is there an
example or documentation or can you explain how the matched filter should
be implemented on yours?
Thanks,
Rich
On Sun, Mar 29, 2015 at 5:18 PM, Tom Rondeau <address@hidden> wrote:
> On Sun, Mar 29, 2015 at 3:47 PM, Andy Walls <address@hidden>
> wrote:
>
>> On Sun, 2015-03-29 at 12:00 -0400, address@hidden
>> wrote:
>>
>>
>> > From: Richard Bell <address@hidden>
>> > To: Karl Koscher <address@hidden>
>> > Cc: "address@hidden" <address@hidden>
>> > Subject: Re: [Discuss-gnuradio] Weird behavior of the
>> > correlate_and_sync block
>> > Message-ID:
>> > <CAMMoi3u0OVyALDYQezdFLPxn_UwkyW2zf-2XAuJV+MOPOOv=
>> address@hidden>
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > I was seeing results with amplitudes like that as well, but
I didn't
>> trust
>> > myself. I didn't push hard enough to get it working. I let
it go. I'm
>> still
>> > need to get it working, for the same reason as you, but I
can't say
>> when I
>> > will be able to put the time in. I'll let you know what happens
when I
>> do,
>> > if no one else comments on this.
>> >
>> > Rich
>> >
>> > On Sat, Mar 28, 2015 at 6:19 PM, Karl Koscher <
>> address@hidden>
>> > wrote:
>> >
>> > > I'm trying to use the correlate_and_sync block to get
an initial
>> timing
>> > > estimate from a packet radio, but it doesn't seem to
work at all. I
>> decided
>> > > to dig a bit deeper and try to figure out what it was
doing. As it
>> turns
>> > > out, the sequence it correlates against seems to be
completely wrong.
>> > > Here's a simple test script to demonstrate the problem:
>> > >
>> > > #!/usr/bin/python
>> > >
>> > > from gnuradio import digital
>> > > from gnuradio.filter import firdes
>> > > from pylab import *
>> > >
>> > > preamble = [1,1,-1,-1] * 10
>> > > taps = firdes.root_raised_cosine(32, 32, 1, 0.35, 11*4*32)
>> > > corr_and_sync = digital.correlate_and_sync_cc(preamble,
taps, 8, 32)
>> > > plot(corr_and_sync.symbols())
>> > > show()
>> > >
>> > >
>> > > This produces a non-deterministic graph, but will often
show wildly
>> > > oscillating samples, with an amplitude as high as 1e31.
Clearly
>> something
>> > > is amiss.
>> > >
>> > > When I extend the preamble to be 64 symbols long, everything
seems to
>> > > work. However, when I change the filter it uses, it
breaks again.
>> > >
>> > > Any ideas what's going on?
>> > >
>> > > - Karl
>>
>> Karl and Rich,
>>
>> The short story is I know why these things happen; check the list
>> archives if you care to learn the whys.
>>
>> You really want the correlate and sync block changes waiting in
this
>> pull request:
>>
>> https://github.com/gnuradio/gnuradio/pull/376
>>
>> You will be much happier with its performance, as I tried to address
>> everything I found amiss with the block.
>>
>> The patches are based on top of Nick Foster's work of specifying
the
>> correlation pattern input by using the GNURadio modulators to
build the
>> target correlation waveform. If you rebuild GNURadio with
these
>> patches, you can look at the example test_corr_and_sync.grc file,
that
>> is in that pull request, for guidance.
>>
>> Hopefully, Tom will merge this in some form in the next release
or two.
>> It is an ABI change, so it just can't be winged in as a fix.
>>
>> HTH,
>> Andy
>
>
> Yeah, I've looked into this and am trying to pull in as much of this
work
> into the 3.7 API so we can get it out there and help people with these
> issues. It's just one of those things that I need more time to focus
just
> on that problem.
>
> Tom
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150330/fced0e07/attachment.html>
------------------------------
Message: 2
Date: Mon, 30 Mar 2015 09:19:51 -0700
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] gr-ais fails?
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252; format=flowed
Did you also clean and rebuild gr-ais?
M
On 29.03.2015 08:53, Ralph A. Schmid, dk5ras wrote:
> Hi,
>
> with latest UHD and Gnuradio built from sources, gr-ais throws this
> error when callin ais_rx:
>
> address@hidden:~$ ais_rx
>
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-143-g8c20712d
>
> -- Operating over USB 3.
>
> -- Initialize CODEC control...
>
> -- Initialize Radio control...
>
> -- Performing register loopback test... pass
>
> -- Performing register loopback test... pass
>
> -- Performing CODEC loopback test... pass
>
> -- Performing CODEC loopback test... pass
>
> -- Asking for clock rate 32.000000 MHz...
>
> -- Actually got clock rate 32.000000 MHz.
>
> -- Performing timer loopback test... pass
>
> -- Performing timer loopback test... pass
>
> -- Setting master clock rate selection to 'automatic'.
>
> -- Tune Request: 162.000000 MHz
>
> -- The RF LO does not support the requested frequency:
>
> -- Requested LO Frequency: 162.000000 MHz
>
> -- RF LO Result: 162.000000 MHz
>
> -- Attempted to use the DSP to reach the requested frequency:
>
> -- Desired DSP Frequency: -0.000000 MHz
>
> -- DSP Result: -0.000000 MHz
>
> -- Successfully tuned to 162.000000 MHz
>
> --
>
> Tuned to 162.000MHz
>
> Setting gain to 38
>
> Gain is 38
>
> Rate is 250000
>
> Using Volk machine: avx_64_mmx_orc
>
> Traceback (most recent call last):
>
> File "/usr/local/bin/ais_rx", line 23, in <module>
>
> main()
>
> File "/usr/local/bin/ais_rx", line 18, in main
>
> tb = ais.radio.ais_radio(options)
>
> File "/usr/local/lib/python2.7/dist-packages/ais/radio.py",
line 88,
> in __init__
>
> self._rx_paths = (ais_rx(161.975e6 - 162.0e6,
options.rate, "A"),
>
> File "/usr/local/lib/python2.7/dist-packages/ais/radio.py",
line 63,
> in __init__
>
> self.demod = ais.ais_demod(options) #ais_demod
takes in complex
> baseband and spits out 1-bit unpacked bitstream
>
> File "/usr/local/lib/python2.7/dist-packages/ais/ais_demod.py",
line
> 37, in __init__
>
> self.preamble_detect = digital.msk_correlate_cc(self.preamble,
0.4,
> self._samples_per_symbol)
>
> AttributeError: 'module' object has no attribute 'msk_correlate_cc'
>
> address@hidden:~$
>
> Any ideas what is wrong?
>
> Ralph.
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 3
Date: Mon, 30 Mar 2015 11:51:37 -0700
From: Richard Bell <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Generating Custom Packet Header
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I've made the default packet generator work for my radio. I now want to
make a custom header. The difference is described below:
*GNU Radio Default Header:* [Payload Length (12 bits) | Packet Number (12
bits) | CRC (12 bits)]
I am using my header for synchronization only. I don't want the CRC check
in there and I don't want packet numbers.
My understanding of how to attack this is as follows:
*1)* Customize packet_header_default.cc which is responsible for making
the
custom header object
*2)* No change needed for the Packet_Header_Generator block
*3)* No change needed for the Packet_Header_Parser block
If this is correct, how should I replace packet_header_default.cc with
packet_header_mycustom.cc, since they are not blocks in GRC? Should I think
of this the same way I would if I were making a custom GRC block, and
follow the custom block tutorials?
Message: 4
Date: Mon, 30 Mar 2015 13:36:30 -0700
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Generating Custom Packet Header
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 30.03.2015 11:51, Richard Bell wrote:
> If this is correct, how should I replace packet_header_default.cc
with
> packet_header_mycustom.cc, since they are not blocks in GRC? Should
I
> think of this the same way I would if I were making a custom GRC block,
> and follow the custom block tutorials?
Kind of. The SWIG magic won't work out-of-the-box, though. Bastian's
gr-ieee-80211a does this, or check out how gr-digital does this.
Cheers,
M
------------------------------
Message: 5
Date: Mon, 30 Mar 2015 22:48:19 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Swig and python import problem due to
other out-of-tree modules used in my out-of-tree module
Message-ID: <address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Jeon,
do you specify gnuradio-dvbt as one of the libraries you link against?
Greetings,
Marcus
On 03/30/2015 06:25 AM, Jeon wrote:
> I've asked this question before. But there are lots of ambiguity and
> uncertainty. Thus, this is the clarification.
>
> I am using Reed-Solomon En/decoder in my own OOT module sources. The
> Reed-Solomon en/decoder are implemented in
> [gr-dvbt](https://github.com/BogdanDIA/gr-dvbt).
>
> Important codes are:
>
>
> [include/reed_solomon.h](https://github.com/BogdanDIA/gr-dvbt/blob/master/include/dvbt/reed_solomon.h)
>
> [include/reed_solomon_enc.h](https://github.com/BogdanDIA/gr-dvbt/blob/master/include/dvbt/reed_solomon_enc.h)
>
> [lib/reed_solomon.cc](https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon.cc)
>
> [lib/reed_solomon_end_impl.h](https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon_enc_impl.h)
>
> [lib/reed_solomon_end_impl.cc](https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon_enc_impl.cc)
>
> I've built and installed my module. But when I import my module in
> Python for tests, error occurs:
>
> >>> import myOOTmodule
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/__init__.py",
line
> 51, in <module>
> from myOOTmodule_swig import *
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
> line 28, in <module>
> _myOOTmodule_swig = swig_import_helper()
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
> line 24, in swig_import_helper
> _mod = imp.load_module('_myOOTmodule_swig',
fp, pathname,
> description)
> ImportError: /usr/local/lib/libgnuradio-myOOTmodule.so:
undefined
> symbol: _ZN2gr4dvbt12reed_solomonC1Eiiiiiiii
>
> You can also see the error above in
> [gist](https://gist.github.com/gsongsong/e07883959f6a339b5d78)
>
> The problem is that the above error occurs since I am using
> gr:dvbt::reed_solomon, which is neither in GNU Radio source tree nor
> in my module.
>
> I don't know the exact reason for this. But in my guess...
> It seems that myOOTmodule thinks gr::dvbt::reed_solomon is a part
of
> myOOTmodule itself. But there is no declaration and implementation
and
> it causes the error.
> Or myOOTmodule has no idea where to import gr:dvbt:reed_solomon.
>
> Another hypothesis is that, an OOT module cannot use other OOT modules
> (in swig-python?). I'm not sure about it. Or, there is a way to do
> this, but I just don't know about it.
>
> Regards,
> Jeon.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Message: 6
Date: Mon, 30 Mar 2015 14:56:25 -0700
From: Richard Bell <address@hidden>
To: Martin Braun <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Generating Custom Packet Header
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Are you referring to the packet_header.i file in the swig folder of
gr-digital? Are there other spots that need to be changed as well?
Rich
On Mon, Mar 30, 2015 at 1:36 PM, Martin Braun <address@hidden>
wrote:
> On 30.03.2015 11:51, Richard Bell wrote:
>
>> If this is correct, how should I replace packet_header_default.cc
with
>> packet_header_mycustom.cc, since they are not blocks in GRC? Should
I
>> think of this the same way I would if I were making a custom GRC
block,
>> and follow the custom block tutorials?
>>
>
> Kind of. The SWIG magic won't work out-of-the-box, though. Bastian's
> gr-ieee-80211a does this, or check out how gr-digital does this.
>
> Cheers,
> M
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150330/30d68f71/attachment.html>
------------------------------
Message: 7
Date: Mon, 30 Mar 2015 18:13:30 -0400
From: Andy Walls <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] QT GUI time sink (float) unnecessary
memmove()?
Message-ID: <address@hidden>
Content-Type: text/plain; charset="UTF-8"
On Sun, 2015-03-29 at 17:20 -0700, Tom Rondeau wrote:
> On Sat, Mar 28, 2015 at 5:32 PM, Andy Walls
> <address@hidden> wrote:
> Andy, if you have a chance, can you check out this new branch:
>
>
> https://github.com/trondeau/gnuradio/tree/qtgui/controlpanel
>
>
>
> It adds the fixes that we talked about. I just want to verify that
> things are still looking and behaving well for you.
I had time to inspect the change for time_sink_f_impl.* but haven't had
time to test yet. What you did was very close to what I did (including
naming the new buffers 'd_fbuffers' :) ), but I will suggest two
improvements:
1. The size of the allocated double 'd_buffers' arrays can now be
reduced from d_buffer_size to d_size, so they only take up 1/2 as much
memory.
2. (I think) You can defer the call to volk_32f_convert_64f() even more,
to when you know for sure plotting is going to happen in the clause that
checks the update time. See the patch in line below.
It works for me.
> The other trick of this branch is if you go into the QT GUI Time Sink
> properties and turn "Control Panel" to Yes. I wouldn't mind
a quick
> bit of feedback there, either.
I'll have some time on Wednesday to recompile and evaluate.
// If delay was set beyond the new boundary,
pull it back.
@@ -427,7 +435,7 @@ namespace gr {
int n;
if(d_trigger_delay) {
for(n = 0; n < d_nconnections; n++) {
- memmove(d_buffers[n], &d_buffers[n][d_size-d_trigger_delay],
d_trigger_delay*sizeof(double));
+ memmove(d_fbuffers[n], &d_fbuffers[n][d_size-d_trigger_delay],
d_trigger_delay*sizeof(float));
}
// Also move the offsets of any tags that
occur in the tail
@@ -606,8 +614,7 @@ namespace gr {
// Copy data into the buffers.
for(n = 0; n < d_nconnections; n++) {
in = (const float*)input_items[idx];
- volk_32f_convert_64f(&d_buffers[n][d_index],
-
&in[1], nitems);
+ memcpy(&d_fbuffers[n][d_index], &in[1],
nitems*sizeof(float));
uint64_t nr = nitems_read(idx);
std::vector<gr::tag_t> tags;
@@ -622,13 +629,13 @@ namespace gr {
// If we've have a trigger and a full d_size of items
in the buffers, plot.
if((d_triggered) && (d_index == d_end)) {
- // Copy data to be plotted to start of buffers.
- for(n = 0; n < d_nconnections; n++) {
- memmove(d_buffers[n], &d_buffers[n][d_start],
d_size*sizeof(double));
- }
-
// Plot if we are able to update
if(gr::high_res_timer_now() - d_last_time
> d_update_time) {
+ // Convert and copy data to be plotted
to start of buffers.
+ for(n = 0; n < d_nconnections; n++)
{
+ volk_32f_convert_64f(&d_buffers[n][0],
+
&d_fbuffers[n][d_start],
d_size);
+ }
d_last_time = gr::high_res_timer_now();
d_qApplication->postEvent(d_main_gui,
new TimeUpdateEvent(d_buffers,
d_size, d_tags));
diff --git a/gr-qtgui/lib/time_sink_f_impl.h b/gr-qtgui/lib/time_sink_f_impl.h
index 2da1db9..d8e2261 100644
--- a/gr-qtgui/lib/time_sink_f_impl.h
+++ b/gr-qtgui/lib/time_sink_f_impl.h
@@ -41,6 +41,7 @@ namespace gr {
int d_nconnections;
Message: 8
Date: Mon, 30 Mar 2015 18:24:55 -0400
From: Andy Walls <address@hidden>
To: Richard Bell <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Weird behavior of the
correlate_and_sync block
Message-ID: <address@hidden>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2015-03-30 at 09:03 -0700, Richard Bell wrote:
> The github block you linked is in working order then?
It works for me.
But of course, per the GPL,
"[...] is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE [...]"
:)
> Is there an example or documentation or can you explain how
the
> matched filter should be implemented on yours?
"If you rebuild GNURadio with these patches, you can look at the example
test_corr_and_sync.grc file, that is in that pull request, for
guidance."
Specifically pay attention to the 'Modulate Vector' block; which lets
you specify a GNURadio modulator to run, a preamble to feed the
modulator, and a post filter; used to build the sample sequence which is
the matched filter sample sequence. The new correlate and sync block
handles time reversal of the sample sequence you give to it.
(Although it doesn't if you update the matched filter sometime later
while the block is running - sorry 1 bug that was not critical enough
for me to fix).
The 'Modulate Vector' block might not be in mainline GNURadio, so you'll
have to pick that up from that pull request too. You could always
"manually" build the sample sequence for the matched filter in
MatLab or
Python and paste it into GNURadio as well.
-Andy
>
> Thanks,
>
> Rich
------------------------------
Message: 9
Date: Mon, 30 Mar 2015 18:29:29 -0700
From: Kevin Reid <address@hidden>
To: GNU Radio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] gr-ais fails?
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252
On Mar 30, 2015, at 9:19, Martin Braun <address@hidden> wrote:
> Did you also clean and rebuild gr-ais?
>
> On 29.03.2015 08:53, Ralph A. Schmid, dk5ras wrote:
[...]
>> self.preamble_detect = digital.msk_correlate_cc(self.preamble,
0.4,
>> self._samples_per_symbol)
>>
>> AttributeError: 'module' object has no attribute 'msk_correlate_cc'
I, too, would like to use gr-ais and hope this problem gets resolved soon
(either by gnuradio accepting the patch or gr-ais offering a ?stable branch?).
Message: 10
Date: Mon, 30 Mar 2015 18:32:28 -0700
From: Nick Foster <address@hidden>
To: Kevin Reid <address@hidden>
Cc: GNU Radio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] gr-ais fails?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Yes, this is my fault. I've been catastrophically lazy about removing the
commits to gr-ais's trunk in order to make it work with mainline GR,
because I've been hoping things would have been integrated sooner. Tell
you
what, I'll create a branch of gr-ais which just includes the required
blocks, in-tree, and push that to the trunk until we get all the GR work
sorted out. It's going to take me some time though.
--n
On Mon, Mar 30, 2015 at 6:29 PM, Kevin Reid <address@hidden>
wrote:
> On Mar 30, 2015, at 9:19, Martin Braun <address@hidden>
wrote:
>
> > Did you also clean and rebuild gr-ais?
> >
> > On 29.03.2015 08:53, Ralph A. Schmid, dk5ras wrote:
> [...]
> >> self.preamble_detect = digital.msk_correlate_cc(self.preamble,
0.4,
> >> self._samples_per_symbol)
> >>
> >> AttributeError: 'module' object has no attribute 'msk_correlate_cc'
>
> I hit this myself just recently.
>
> Apparently, trunk gr-ais is ?too new?: it requires a block
> gnuradio.digital.msk_correlate_cc, which was proposed but not yet
merged:
> https://github.com/gnuradio/gnuradio/pull/376
>
> I, too, would like to use gr-ais and hope this problem gets resolved
soon
> (either by gnuradio accepting the patch or gr-ais offering a ?stable
> branch?).
>
> --
> Kevin Reid
<http://switchb.org/kpreid/>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150330/a53824f0/attachment.html>
------------------------------
Message: 11
Date: Tue, 31 Mar 2015 15:11:48 +0900
From: Jeon <address@hidden>
To: Discuss GNU Radio mailing list <address@hidden>
Subject: Re: [Discuss-gnuradio] Swig and python import problem due to
other out-of-tree modules used in my out-of-tree module
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Dear Douglas,
Thank you for your answer.
Unfortunately, I couldn't find other modules and projects that use gr-dvbt
in their codes. Thus, I feel sort of being frustrated :(
Or maybe I can handle it if you give me some details about CMakeLists.
As
you know, there are a number of CmakeLists in the project. Can it be done
by modifying and fixing CMakeLists.txt under swig, python or project root
directory?
If you have any better suggestions, I will be very thankful to it.
Also, I will report my progress as soon as possible.
Regards,
Jeon.
2015-03-31 0:22 GMT+09:00 Anderson, Douglas J. <address@hidden>:
> Jeon,
>
> I've recently dealt with a similar problem. Chances are that
if things
> are building and installing correctly but the error is in the SWIG
import,
> the actual problem lies in your CMakeLists.txt... seems like the C++
linker
> is being smart enough to get things linked correctly but SWIG needs
you to
> be a bit more explicit.
>
> Is there another project that includes Reed-Solomon that you
can
> reference? See what changes they made to their CMakesLists.txt to
get SWIG
> to be happy.
>
> -Doug
> ------------------------------
> *From:* address@hidden
> address@hidden on behalf
of
> Jeon address@hidden
> *Sent:* Sunday, March 29, 2015 10:25 PM
> *To:* Discuss GNU Radio mailing list
> *Subject:* [Discuss-gnuradio] Swig and python import problem due to
other
> out-of-tree modules used in my out-of-tree module
>
> I've asked this question before. But there are lots of
ambiguity and
> uncertainty. Thus, this is the clarification.
>
> I am using Reed-Solomon En/decoder in my own OOT module sources. The
> Reed-Solomon en/decoder are implemented in [gr-dvbt](
> https://github.com/BogdanDIA/gr-dvbt).
>
> Important codes are:
>
> [include/reed_solomon.h](
> https://github.com/BogdanDIA/gr-dvbt/blob/master/include/dvbt/reed_solomon.h
> )
> [include/reed_solomon_enc.h](
> https://github.com/BogdanDIA/gr-dvbt/blob/master/include/dvbt/reed_solomon_enc.h
> )
> [lib/reed_solomon.cc](
> https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon.cc)
> [lib/reed_solomon_end_impl.h](
> https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon_enc_impl.h
> )
> [lib/reed_solomon_end_impl.cc](
> https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon_enc_impl.cc
> )
>
> I've built and installed my module. But when I import my module
in Python
> for tests, error occurs:
>
> >>> import myOOTmodule
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/__init__.py",
line 51,
> in <module>
> from myOOTmodule_swig import *
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
> line 28, in <module>
> _myOOTmodule_swig = swig_import_helper()
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
> line 24, in swig_import_helper
> _mod = imp.load_module('_myOOTmodule_swig',
fp, pathname,
> description)
> ImportError: /usr/local/lib/libgnuradio-myOOTmodule.so:
undefined
> symbol: _ZN2gr4dvbt12reed_solomonC1Eiiiiiiii
>
> You can also see the error above in [gist](
> https://gist.github.com/gsongsong/e07883959f6a339b5d78)
>
> The problem is that the above error occurs since I am using
> gr:dvbt::reed_solomon, which is neither in GNU Radio source tree nor
in my
> module.
>
> I don't know the exact reason for this. But in my guess...
> It seems that myOOTmodule thinks gr::dvbt::reed_solomon is a part
of
> myOOTmodule itself. But there is no declaration and implementation
and it
> causes the error.
> Or myOOTmodule has no idea where to import gr:dvbt:reed_solomon.
>
> Another hypothesis is that, an OOT module cannot use other OOT
modules
> (in swig-python?). I'm not sure about it. Or, there is a way to do
this,
> but I just don't know about it.
>
> Regards,
> Jeon.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150331/65b02dce/attachment.html>
------------------------------
Message: 12
Date: Tue, 31 Mar 2015 13:21:13 +0530
From: Vishwanatha H G <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Error in creating a block
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Message: 13
Date: Tue, 31 Mar 2015 11:22:07 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Error in creating a block
Message-ID: <address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Vishwanatha,
you've forgot to modify your block's XML description, which you can find
under /grc in your out of tree module.
I'd like to point you to the guided tutorials [1], which contain
information on that topic [2].
On 03/31/2015 09:51 AM, Vishwanatha H G wrote:
> Hi..
> I created a block named 'cost'. But it showing the error
as in
> screenshot attached what is the problem with this? thanks for your
advice.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Message: 14
Date: Tue, 31 Mar 2015 11:32:27 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Swig and python import problem due to
other out-of-tree modules used in my out-of-tree module
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252
Hi Jeon,
typically, you'd call a FindSomething function in the root CMakeList
find_library(GR_DVBT_LIBRARY
NAMES
gnuradio-dvbt
PATHS
/usr/lib
/usr/local/lib
/opt/local/lib
/sw/lib
)
or so. I guess "gnuradio-dvbt.so" should be the name of the installed
gr-dvbt library -- please verify that this is correct.
Then add the resulting library name to the target_link_libraries
directive in lib/CMakeList.txt:
target_link_libraries(<project_name> ${Boost_LIBRARIES}
${GNURADIO_ALL_LIBRARIES} ${GR_DVBT_LIBRARY})
and
target_link_libraries(test-<project_name> ${Boost_LIBRARIES}
${GNURADIO_ALL_LIBRARIES} ${GR_DVBT_LIBRARY} <project_name>)
How is CMake able to find the headers you need to compile your module?
If you have written functionality to detect these headers, you can
probably do the same for the compiled gr-dvbt libraries.
Greetings,
Marcus
On 03/31/2015 08:11 AM, Jeon wrote:
>
> Or maybe I can handle it if you give me some details about CMakeLists.
> As you know, there are a number of CmakeLists in the project. Can
it
> be done by modifying and fixing CMakeLists.txt under swig, python
or
> project root directory?
------------------------------
Message: 15
Date: Tue, 31 Mar 2015 12:37:03 +0200
From: Gisle Vanem <address@hidden>
To: GnuRadio <address@hidden>
Subject: [Discuss-gnuradio] Illegal CustomBuild for MSVC 18
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I have had some more success building Gr using MSVC v18
than MSVC v16 previously (nearly impossible). Besides the
high noise-level (due to cmake/msvc/config.h), the C++ building
seems fine.
But the build stops in 'build\gnuradio-runtime\swig'
at some CustomBuild/CustomCommand. Here is from the MSbuild
output:
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
setlocal
"" << !! because of
this
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
setlocal
""
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
Building Custom Rule F:/gv/dx-radio/gnuradio-3.x/gnuradio-runtime/swig/CMakeLists.txt
'""' is not recognized as an internal or external command,
What command in 'gnuradio-runtime\swig\CMakeLists.txt' could trigger this
illegal CMD batch snippet?
BTW. I generated the .sln/.vcxproj files by a script:
setlocal
cd build
set OPT=-DCMAKE_CXX_COMPILER=cl -DCMAKE_C_COMPILER=cl ^
-DCMAKE_CXX_COMPILER_ENV_VAR=-nologo -O2 -MD
^
-DCMAKE_C_COMPILER_ENV_VAR=-nologo -O2 -MD
^
-Wno-dev -DCMAKE_BUILD_TYPE="Release"
-DENABLE_TESTING=1 ^
-DPORTAUDIO_LIBRARIES=%MINGW32%/src/Sound/Portaudio/lib/portaudio_static_x86.lib
cmake %OPT% -G "Visual Studio 12 2013" ..
...
--
--gv
------------------------------
Message: 16
Date: Tue, 31 Mar 2015 08:55:03 -0400
From: "Murphy, John" <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] Copying OOT blocks to a different system
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=UTF-8
Hello again GNU Radio'ers,
We are trying to copy an OOT module with custom C++ blocks from one
system to another. We've done this successfully before where the
systems were nearly exact copies, but now we are trying to do this
between systems that are different, in this particular case the source
is a Fedora system and the destination is a VM LinuxMint system. The
source system, and I believe the destination system, were installed
using build-gnuradio.
The essentials of the procedure have been to use gr_modtool to
generate a dummy module and block on the destination system, copy the
required source files, and build and install.
Well... we are getting the "AttributeError: module 'mymodulename'
has
no attribute 'myblockname'."
We've hacked through all the stuff we could think of (ldconfig,
PYTHONPATH, /etc/ld/so.conf.d, config.conf), and have not found
anything that looks wrong to us.
Oddly, when the build was done before we added what should have been a
required item in the module cmake to use FFT, the make did not
generate an error as I would think it should. But when we purposely
garbled a line of code to check, it did indeed generate an error.
Any idea what this could be?
Also, is there somewhere an outline of how to go about this
module/block copy process?
Thanks again,
- John
------------------------------
Message: 17
Date: Tue, 31 Mar 2015 14:57:27 +0200
From: Marcus M?ller <address@hidden>
To: Vishwanatha H G <address@hidden>,
GNURadio
Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Error in creating a block
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi Vishwanatha,
please stick to the list.
from gnuradio import project
ImportError: cannot import name project
indicates there is some line in your source code where you do that,
"from gnuradio import project". Maybe you made a mistake in the
<import>
tag in your XML, maybe it's in your source code.
I'd search for "from gnuradio import project" inside your source
code,
and if that doesn't yield where this happens, for "project".
Message: 18
Date: Tue, 31 Mar 2015 15:04:05 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Copying OOT blocks to a different
system
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252
Hi John,
you shouldn't use gr_modtool to create a new module on your destination
system -- just take your OOT's folder, and copy it over to the
destination system, deleting/omitting your build folder. Then rebuild
and install -- CMake should make sure to find all the libraries on the
destination system itself.
In fact, OOTs were designed to be self-contained and transportable like
this -- which is what tools like pybombs rely on: you can just copy/git
clone the OOT directory tree, mkdir build, cd build, cmake .., make and
make install and be set.
Greetings,
Marcus
On 03/31/2015 02:55 PM, Murphy, John wrote:
> Hello again GNU Radio'ers,
>
> We are trying to copy an OOT module with custom C++ blocks from one
> system to another. We've done this successfully before where the
> systems were nearly exact copies, but now we are trying to do this
> between systems that are different, in this particular case the source
> is a Fedora system and the destination is a VM LinuxMint system. The
> source system, and I believe the destination system, were installed
> using build-gnuradio.
>
> The essentials of the procedure have been to use gr_modtool to
> generate a dummy module and block on the destination system, copy
the
> required source files, and build and install.
>
> Well... we are getting the "AttributeError: module 'mymodulename'
has
> no attribute 'myblockname'."
>
> We've hacked through all the stuff we could think of (ldconfig,
> PYTHONPATH, /etc/ld/so.conf.d, config.conf), and have not found
> anything that looks wrong to us.
>
> Oddly, when the build was done before we added what should have been
a
> required item in the module cmake to use FFT, the make did not
> generate an error as I would think it should. But when we purposely
> garbled a line of code to check, it did indeed generate an error.
>
> Any idea what this could be?
> Also, is there somewhere an outline of how to go about this
> module/block copy process?
>
> Thanks again,
> - John
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 19
Date: Tue, 31 Mar 2015 15:58:14 +0200
From: "Ralph A. Schmid, dk5ras" <address@hidden>
To: "'Martin Braun'" <address@hidden>,
<address@hidden>
Subject: Re: [Discuss-gnuradio] gr-ais fails?
Message-ID: <address@hidden>
Content-Type: text/plain;
charset="us-ascii"
Yes, I did, even deleted the gr-ais folder and loaded a completely new
git
repo...
Ralph.
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden]
On Behalf Of
> Martin Braun
> Sent: Monday, March 30, 2015 6:20 PM
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] gr-ais fails?
>
> Did you also clean and rebuild gr-ais?
>
> M
>
> On 29.03.2015 08:53, Ralph A. Schmid, dk5ras wrote:
> > Hi,
> >
> > with latest UHD and Gnuradio built from sources, gr-ais throws
this
> > error when callin ais_rx:
> >
> > address@hidden:~$ ais_rx
> >
> > linux; GNU C++ version 4.8.2; Boost_105400;
> > UHD_003.008.002-143-g8c20712d
> >
> > -- Operating over USB 3.
> >
> > -- Initialize CODEC control...
> >
> > -- Initialize Radio control...
> >
> > -- Performing register loopback test... pass
> >
> > -- Performing register loopback test... pass
> >
> > -- Performing CODEC loopback test... pass
> >
> > -- Performing CODEC loopback test... pass
> >
> > -- Asking for clock rate 32.000000 MHz...
> >
> > -- Actually got clock rate 32.000000 MHz.
> >
> > -- Performing timer loopback test... pass
> >
> > -- Performing timer loopback test... pass
> >
> > -- Setting master clock rate selection to 'automatic'.
> >
> > -- Tune Request: 162.000000 MHz
> >
> > -- The RF LO does not support the requested frequency:
> >
> > -- Requested LO Frequency: 162.000000 MHz
> >
> > -- RF LO Result: 162.000000 MHz
> >
> > -- Attempted to use the DSP to reach the requested frequency:
> >
> > -- Desired DSP Frequency: -0.000000 MHz
> >
> > -- DSP Result: -0.000000 MHz
> >
> > -- Successfully tuned to 162.000000 MHz
> >
> > --
> >
> > Tuned to 162.000MHz
> >
> > Setting gain to 38
> >
> > Gain is 38
> >
> > Rate is 250000
> >
> > Using Volk machine: avx_64_mmx_orc
> >
> > Traceback (most recent call last):
> >
> > File "/usr/local/bin/ais_rx", line 23,
in <module>
> >
> > main()
> >
> > File "/usr/local/bin/ais_rx", line 18,
in main
> >
> > tb = ais.radio.ais_radio(options)
> >
> > File "/usr/local/lib/python2.7/dist-packages/ais/radio.py",
line
> > 88, in __init__
> >
> > self._rx_paths = (ais_rx(161.975e6 - 162.0e6,
options.rate, "A"),
> >
> > File "/usr/local/lib/python2.7/dist-packages/ais/radio.py",
line
> > 63, in __init__
> >
> > self.demod = ais.ais_demod(options) #ais_demod
takes in complex
> > baseband and spits out 1-bit unpacked bitstream
> >
> > File "/usr/local/lib/python2.7/dist-packages/ais/ais_demod.py",
> > line 37, in __init__
> >
> > self.preamble_detect = digital.msk_correlate_cc(self.preamble,
> > 0.4,
> > self._samples_per_symbol)
> >
> > AttributeError: 'module' object has no attribute 'msk_correlate_cc'
> >
> > address@hidden:~$
> >
> > Any ideas what is wrong?
> >
> > Ralph.
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 20
Date: Tue, 31 Mar 2015 15:59:43 +0200
From: "Ralph A. Schmid, dk5ras" <address@hidden>
To: "'Nick Foster'" <address@hidden>, "'Kevin
Reid'"
<address@hidden>
Cc: 'GNU Radio Discussion List' <address@hidden>
Subject: Re: [Discuss-gnuradio] gr-ais fails?
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
Hey, thanks a lot! I will give it a shot when finished, maybe I will be
in reach of some ships them again.
Ralph.
From: address@hidden [mailto:address@hidden]
On Behalf Of Nick Foster
Sent: Tuesday, March 31, 2015 3:32 AM
To: Kevin Reid
Cc: GNU Radio Discussion List
Subject: Re: [Discuss-gnuradio] gr-ais fails?
Yes, this is my fault. I've been catastrophically lazy about removing the
commits to gr-ais's trunk in order to make it work with mainline GR, because
I've been hoping things would have been integrated sooner. Tell you what,
I'll create a branch of gr-ais which just includes the required blocks,
in-tree, and push that to the trunk until we get all the GR work sorted
out. It's going to take me some time though.
--n
On Mon, Mar 30, 2015 at 6:29 PM, Kevin Reid <address@hidden <mailto:address@hidden>
> wrote:
On Mar 30, 2015, at 9:19, Martin Braun <address@hidden <mailto:address@hidden>
> wrote:
> Did you also clean and rebuild gr-ais?
>
> On 29.03.2015 08:53, Ralph A. Schmid, dk5ras wrote:
[...]
>> self.preamble_detect = digital.msk_correlate_cc(self.preamble,
0.4,
>> self._samples_per_symbol)
>>
>> AttributeError: 'module' object has no attribute 'msk_correlate_cc'
I, too, would like to use gr-ais and hope this problem gets resolved soon
(either by gnuradio accepting the patch or gr-ais offering a ?stable branch?).
Message: 21
Date: Tue, 31 Mar 2015 23:37:18 +0900
From: Jeon <address@hidden>
To: Discuss GNU Radio mailing list <address@hidden>
Subject: Re: [Discuss-gnuradio] Swig and python import problem due to
other out-of-tree modules used in my out-of-tree module
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Dear, Marcus.
Thanks, it's very helpful. But, stil somethings unresolved.
pkg_check_modules(PC_DVBT gnuradio-dvbt): returns package
'gnuradio-dvbt' not found
Although I've changed gnuradio-dvbt to gr-dvbt, dvbt gnuradio_dvbt,
gr_dvbt, libgnuradio-dvbt and other possible combinations, nothings
different.
But DVBT_LIBRARY returns /usr/local/lib/libgnuradio-dvbt.so and
DVBT_INCLUDE_DIR returns /usr/local/include.
I think this part is correct.
And in python:
>>> import mymodule
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/__init__.py",
line 51,
in <module>
from myOOTmodule_swig import *
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
line 28, in <module>
_myOOTmodule_swig = swig_import_helper()
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_myOOTmodule_swig',
fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-myOOTmodule.so: undefined
symbol: _ZN2gr4dvbt12reed_solomonC1Eiiiiiiii
It is the same as the previous.
.........
After some googling and searching, I found that gr-dvbt is not present
in
'pkg-config --list-all'.
I think it would be a bit relevant to this problem.
If it is the case, I'd better think to use IT++ Reed Solomon.
I'll let you know if I have further progress.
Regards,
Jeon.
2015-03-31 18:32 GMT+09:00 Marcus M?ller <address@hidden>:
> Hi Jeon,
>
> typically, you'd call a FindSomething function in the root CMakeList
>
> find_library(GR_DVBT_LIBRARY
> NAMES
> gnuradio-dvbt
> PATHS
> /usr/lib
> /usr/local/lib
> /opt/local/lib
> /sw/lib
> )
> or so. I guess "gnuradio-dvbt.so" should be the name of
the installed
> gr-dvbt library -- please verify that this is correct.
>
> Then add the resulting library name to the target_link_libraries
> directive in lib/CMakeList.txt:
>
> target_link_libraries(<project_name> ${Boost_LIBRARIES}
> ${GNURADIO_ALL_LIBRARIES} ${GR_DVBT_LIBRARY})
> and
> target_link_libraries(test-<project_name> ${Boost_LIBRARIES}
> ${GNURADIO_ALL_LIBRARIES} ${GR_DVBT_LIBRARY} <project_name>)
>
> How is CMake able to find the headers you need to compile your module?
> If you have written functionality to detect these headers, you can
> probably do the same for the compiled gr-dvbt libraries.
>
> Greetings,
> Marcus
>
>
>
> On 03/31/2015 08:11 AM, Jeon wrote:
> >
> > Or maybe I can handle it if you give me some details about CMakeLists.
> > As you know, there are a number of CmakeLists in the project.
Can it
> > be done by modifying and fixing CMakeLists.txt under swig, python
or
> > project root directory?
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150331/5061c39d/attachment.html>
------------------------------
Message: 22
Date: Tue, 31 Mar 2015 10:42:43 -0400
From: Mike Harpe <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] GNU Radio on Raspberry Pi Model 2??
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
What's the best way to get GNU Radio working on the new Raspberry Pi 2?
I
have tried a straight from source compile and just installing the package.
Both methods ended up not being able to see my FunCube Dongle Pro+ due
to
ALSA issues. I am not sufficiently experienced with ALSA to fix it myself.
Message: 23
Date: Tue, 31 Mar 2015 16:50:48 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Swig and python import problem due to
other out-of-tree modules used in my out-of-tree module
Message-ID: <address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Jeon,
This looks very proper, but since gr-dvbt doesn't supply a pkgconfig
(.pc) file, you can't use pkg_check_modules; the raw find_library call
you use should work, though.
also, you set DVBT_LIBRARY, so you'll have to use
target_link_libraries(gnuradio-mymodule ${DVBT_LIBRARY})
(notice the singular LIBRARY).
Greetings,
Marcus
On 03/31/2015 04:37 PM, Jeon wrote:
> Dear, Marcus.
>
> Thanks, it's very helpful. But, stil somethings unresolved.
>
> What I've done is:
>
> In CMakeLists.txt of root:
>
> find_package(DVBT)
> if (NOT DVBT_FOUND) /* ommited */ endif()
> include_directories(
> /* omitted */
> ${DVBT_INCLUDE_DIR}
> )
>
> Add
> cmake/Modules/[FindDVBT.cmake](https://gist.github.com/gsongsong/49ec2cf84d7907c7ceb0).
> It's quite long.
> And I found that shared object (so) is libgnuradio-dvbt.so.
>
> In lib/CMakeLists.txt:
>
> target_link_libraries(gnuradio-mymodule ${DVBT_LIBRARIES})
>
> A result of build and installation is:
>
> pkg_check_modules(PC_DVBT gnuradio-dvbt): returns package
> 'gnuradio-dvbt' not found
>
> Although I've changed gnuradio-dvbt to gr-dvbt, dvbt gnuradio_dvbt,
> gr_dvbt, libgnuradio-dvbt and other possible combinations, nothings
> different.
>
> But DVBT_LIBRARY returns /usr/local/lib/libgnuradio-dvbt.so and
> DVBT_INCLUDE_DIR returns /usr/local/include.
> I think this part is correct.
>
> And in python:
>
> >>> import mymodule
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/__init__.py",
line
> 51, in <module>
> from myOOTmodule_swig import *
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
> line 28, in <module>
> _myOOTmodule_swig = swig_import_helper()
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
> line 24, in swig_import_helper
> _mod = imp.load_module('_myOOTmodule_swig',
fp, pathname,
> description)
> ImportError: /usr/local/lib/libgnuradio-myOOTmodule.so:
undefined
> symbol: _ZN2gr4dvbt12reed_solomonC1Eiiiiiiii
>
> It is the same as the previous.
>
> .........
>
> After some googling and searching, I found that gr-dvbt is not present
> in 'pkg-config --list-all'.
> I think it would be a bit relevant to this problem.
> If it is the case, I'd better think to use IT++ Reed Solomon.
>
> I'll let you know if I have further progress.
>
> Regards,
> Jeon.
>
>
>
> 2015-03-31 18:32 GMT+09:00 Marcus M?ller <address@hidden
> <mailto:address@hidden>>:
>
> Hi Jeon,
> > typically, you'd call a FindSomething
function in the root CMakeList
>
> find_library(GR_DVBT_LIBRARY
> NAMES
> gnuradio-dvbt
> PATHS
> /usr/lib
> /usr/local/lib
> /opt/local/lib
> /sw/lib
> )
> or so. I guess "gnuradio-dvbt.so" should be
the name of the installed
> gr-dvbt library -- please verify that this is correct.
>
> Then add the resulting library name to the target_link_libraries
> directive in lib/CMakeList.txt:
>
> target_link_libraries(<project_name> ${Boost_LIBRARIES}
> ${GNURADIO_ALL_LIBRARIES} ${GR_DVBT_LIBRARY})
> and
> target_link_libraries(test-<project_name> ${Boost_LIBRARIES}
> ${GNURADIO_ALL_LIBRARIES} ${GR_DVBT_LIBRARY} <project_name>)
>
> How is CMake able to find the headers you need to compile
your module?
> If you have written functionality to detect these headers,
you can
> probably do the same for the compiled gr-dvbt libraries.
>
> Greetings,
> Marcus
>
>
>
> On 03/31/2015 08:11 AM, Jeon wrote:
> >
> > Or maybe I can handle it if you give me some details
about
> CMakeLists.
> > As you know, there are a number of CmakeLists in
the project. Can it
> > be done by modifying and fixing CMakeLists.txt
under swig, python or
> > project root directory?
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden <mailto:address@hidden>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio