Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install problems

For what it's worth, I have both working fine on a c7 box here, I did it from source though, not through pybombs. I had to build a couple packages, such as boost, but it definitely can be done, at least as of a few months ago.

On Oct 7, 2016 11:55 AM, "Chad Spooner" <address@hidden> wrote:

All I really need in the short term is UHD on CentOS 7.

Is it the consensus of the group is that UHD/gnuradio is not installable
on CentOS 7? I haven't seen any suggestions about the python-zmq
problem below.

Chad

On Wed, 2016-10-05 at 10:34 -0700, Chad M. Spooner wrote:
Martin, Marcus: Thanks for the helpful replies.

All: I think I messed up on subscribing to the mail list by selecting Digest, and I've tried to undo that. For now, I have to reply to the Digest I got this morning.

I updated the recipes as suggested, and did a new installation. The first error was that somehow QT 4 was not in my (root's) path, QT 3.3 was, so I fixed that. (The symptom was that 'qmake' was not found by the installer.)

Then I did another install and got to the point where the installer wants to install python-zmq:

checking whether g++ supports C++11 features with -std=c++11... yes
./configure: line 17775: syntax error near unexpected token `QT,'
./configure: line 17775: ` PKG_CHECK_MODULES(QT, QtCore >= 4.3, QtNetwork >= 4.3, have_qt=yes, have_qt=no)'
PyBOMBS.Packager.source - ERROR - Configuration failed after running at least twice.
PyBOMBS.Packager.source - ERROR - Problem occurred while building package apache-thrift:
Configuration failed
PyBOMBS.PackageManager - WARNING - Optional package apache-thrift failed to install.
PyBOMBS.install_manager - INFO - Installation successful.
PyBOMBS.install_manager - INFO - Installing package: liblog4cpp
00549 kB / 00549 kB (100%)
Configuring: (100%) [====================================================================================]
Building: (100%) [====================================================================================]
Installing: (100%) [====================================================================================]
PyBOMBS.install_manager - INFO - Installation successful.
PyBOMBS.install_manager - INFO - Installing package: zeromq
02084 kB / 02084 kB (100%)
Configuring: (100%) [====================================================================================]
Building: (100%) [====================================================================================]
Installing: (100%) [====================================================================================]
PyBOMBS.install_manager - INFO - Installation successful.
PyBOMBS.install_manager - INFO - Installing package: python-zmq
PyBOMBS.Packager.source - WARNING - Cannot find a source URI for package python-zmq
PyBOMBS.install_manager - ERROR - Error installing package python-zmq. Aborting.

Chad

On 2016-10-05 09:00, address@hiddenorg wrote:

Send Discuss-gnuradio mailing list submissions to
    address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
    discuss-gnuradio-request@gnu.org

You can reach the person managing the list at
    discuss-gnuradio-owner@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."

Today's Topics:

   1. Replacement for packet encoder/decoder (Damindra Bandara)
   2. Re: Block Thread question (Marcus M?ller)
   3. Re: Block Thread question (Garver, Paul W)
   4. Re: Fwd: Correlation Estimator in 3.7.10 (devin kelly)
   5. Re: Fwd: Correlation Estimator in 3.7.10 (Steven Knudsen)
   6. UHD/gnuradio on CentOS 7 install problems (Chad M. Spooner)
   7. Re: UHD/gnuradio on CentOS 7 install problems (Marcus M?ller)
   8. Re: UHD/gnuradio on CentOS 7 install problems (Martin Braun)

----------------------------------------------------------------------

Message: 1
Date: Tue, 4 Oct 2016 12:40:10 -0400
From: Damindra Bandara <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Replacement for packet encoder/decoder
Message-ID:
    <CANpceN-aihkrnJuFMbwr9a2J9XyA=b-address@hiddengmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

I have a flowgraph that uses packet encoder at the transmitter end and a
decoder at the receiver end. I updated GNURadio to the latest version and
saw that the packet encoder/decoder are marked as deprecated. My current
work flows are as follows.

TX end: message source-->packet encoder-->modulator-->USRP sink
RX end : USRP source --> synchronization blocks(for phase modulation)-->
demodulator--> packet decoder--> message sink

Is there a replacement for packet encoder/decoder in the latest version? I
appreciate if you could give me some information regarding this.

Thank you,
Damindra

--
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20161004/75f11fab/attachment.html>

------------------------------

Message: 2
Date: Tue, 4 Oct 2016 09:44:05 -0700
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Block Thread question
Message-ID: <8518d7c5-bb52-b44a-df51-address@hidden>
Content-Type: text/plain; charset="windows-1252"

Hi Jake,

yes, that's true: The block_executer practically goes through an endless
loop between handling input samples with (general_)work and handling
messages with the registered message handler. The whole point of that is
that you can send a message that would (logically) change something in
the operation of the block, and it will never interfere with the
operation of work ? thread-safety! (imagine, for example, you changed
the number of taps of a FIR filter right in the middle of that filter's
operation ? that would definitely lead to some unexpected results).

Best regards,

Marcus

On 10/04/2016 08:09 AM, Gavin Jacobs wrote:

I am writing a block which takes a PDU input and produces a stream
output. I used a source block template with zero stream inputs, one
message input, and one stream output. I have implemented a message
handler and I can see my messages are being received. I need to pass
data from the PDU message handler to work(). I looked at the code for
PDU_to_tagged_stream and it appears that they use a private member
(d_curr_len) to communicate from the message handler to work - which
implies that the message handler and work are on the same thread. Is
this correct? i.e. can I use a plain FIFO queue from message handler
to work, or do I need a thread safe queue?

Thanks,

Jake

_______________________________________________
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/20161004/985cacb3/attachment.html>

------------------------------

Message: 3
Date: Tue, 4 Oct 2016 17:35:34 +0000
From: "Garver, Paul W" <address@hidden>
To: Marcus M?ller <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Block Thread question
Message-ID: <9707D576-16C7-427D-9AC9-address@hidden>
Content-Type: text/plain; charset="windows-1252"

Does you block take the packet length as a parameter (vs. reading from metadata)? I think this is a block which should exist in the GR baseline, if your implementation is general enough.

PWG
On Oct 4, 2016, at 12:44 PM, Marcus M?ller <address@hidden<mailto:address@hiddencom>> wrote:

Hi Jake,
yes, that's true: The block_executer practically goes through an endless loop between handling input samples with (general_)work and handling messages with the registered message handler. The whole point of that is that you can send a message that would (logically) change something in the operation of the block, and it will never interfere with the operation of work ? thread-safety! (imagine, for example, you changed the number of taps of a FIR filter right in the middle of that filter's operation ? that would definitely lead to some unexpected results).

Best regards,
Marcus

On 10/04/2016 08:09 AM, Gavin Jacobs wrote:
I am writing a block which takes a PDU input and produces a stream output. I used a source block template with zero stream inputs, one message input, and one stream output. I have implemented a message handler and I can see my messages are being received. I need to pass data from the PDU message handler to work(). I looked at the code for PDU_to_tagged_stream and it appears that they use a private member (d_curr_len) to communicate from the message handler to work - which implies that the message handler and work are on the same thread. Is this correct? i.e. can I use a plain FIFO queue from message handler to work, or do I need a thread safe queue?

Thanks,
Jake

_______________________________________________
Discuss-gnuradio mailing list
address@hidden<mailto:address@hiddenorg>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden<mailto:address@hiddenorg>
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/20161004/f3864ea7/attachment.html>

------------------------------

Message: 4
Date: Tue, 4 Oct 2016 15:31:20 -0400
From: devin kelly <address@hidden>
To: Steven Knudsen <address@hidden>
Cc: GNURadio Discussion List <address@hidden>, Knud
    <address@hidden>
Subject: Re: [Discuss-gnuradio] Fwd: Correlation Estimator in 3.7.10
Message-ID:
    <CAANLyuYwhZ6YDBfpprFB_ZhEz6aWaPECsR9aqfkDxG_dr69B-g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Steven,

I've had the exact same problem as you - my flowgraphs from 3.7.9 worked
well but now I'm getting a lot of false detections from this block.

Is this really how this block is supposed to perform? We just have to use
trial and error to find the right threshold?

Thanks For Any Help,
Devin

On Tue, Sep 27, 2016 at 11:37 AM, Steven Knudsen <address@hidden> wrote:

Alright, after some more thought I believe I understand what is going on.

By looking at the cross-correlation power for the current input samples,
the threshold can be calculated as a desired false alarm rate. An
?arbitrary? threshold can be set independently of the received signal power.

Unfortunately, for the test_corr_est.grc example, you just can?t set the
threshold high enough to avoid false alarms. I tried the CE block with up
to 0.999999 for the threshold and it was still a mess, though much better.

That said, for my own application/flowgraph, setting the CE block
threshold to 0.9999 appears to work. I can set as ?low? as 0.999, but
that?s it.

This makes me wonder why bother to have a threshold parameter at all?
Maybe just set the calculated d_pfa value to 10 or something and be done
with it. Of course, we all hate magic numbers, and so doing would introduce
a second number to the algorithm (the first is a multiplier of 4 in the
peak thresholding logic).

Thanks for your patience?

Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen

*Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt ist
zu erreichen. - Franz Kafka*

Begin forwarded message:

*From: *Steven Knudsen <address@hidden>
*Subject: **Correlation Estimator in 3.7.10*
*Date: *September 27, 2016 at 07:40:17 MDT
*To: *GNURadio Discussion List <address@hidden>
*Cc: *Knud <address@hidden>

Hi All,

I am pretty confused with some of the changes to the corr_est_cc_impl.cc
threshold detection algorithm.

Previously, in _set_threshold(), the zero-offset autocorrelation of the
reference symbols was computed and scaled by the desired relative threshold
when the correlation estimator is instantiated to provide a fixed (constant
for the run) threshold (d_thresh). That makes sense to me and appeared to
work pretty well.

Now, in _set_threshold(), a XXXX is calculated as d_pfa = -logf(1.0f -
threshold) . In the work function, the detection threshold is calculated
anew on each invocation as the mean value of the square of the current
correlation of the reference symbols with the input symbols, scaled by
d_pfa.

How can the threshold for detecting the peak of the correlation against
the reference symbols be a function of the input symbols? I know that using
an absolute threshold based on only the reference symbols may be a problem
because you can?t know the magnitude of the received input symbols, but I
think that?s why there is a block callback for set_threshold().

The net result is that when one runs the correlation estimator, a bunch of
peaks are output in the vicinity of the sync sequence in the input stream.
The test_corr_est.grc example in gr-digital shows this well.

I checked the commit history and the only relevant comment is ?Works with
arbitrary scaling?. This suggests that the changes are meant to include
in the threshold the effect of arbitrary input signal power, which does
make some sense. Again, I thought that was why there was a callback, but
even that is clunky and I could be wrong.

Anyway, all I know is that the correlation estimator used to work really
well for me and is now, in my applications, broken badly. Maybe I?m not
setting it up correctly, but AFAIK the block parameters are the same.

Thanks for your consideration of this question,

steven

Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen

*All the wires are cut, my friendsLive beyond the severed ends. Louis
MacNeice*

_______________________________________________
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/20161004/fb475eec/attachment.html>

------------------------------

Message: 5
Date: Tue, 4 Oct 2016 14:23:24 -0600
From: Steven Knudsen <address@hidden>
To: devin kelly <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Fwd: Correlation Estimator in 3.7.10
Message-ID: <2B4339A2-C07B-42EF-835C-address@hidden>
Content-Type: text/plain; charset="utf-8"

Hey Dean,

For what it?s worth, I?ve resorted to two hacks.

1) where the sum of consecutive correlation mag squared samples is compared to 4*detection, I?ve gone to 8*detection. With the block threshold set to 0.999999, this results in threshold levels (compared to the peak correlation value) of 32 to 78 %.
2) I added a variable to track the max cross-correlation magnitude for samples that exceed the 8*detection threshold. Then i compare those (peak) samples to that max/4 and those that are above, I let pass.

I had to do the latter because I was seeing false correlations at the very end of my TDMA packets. I think they are due to the tx-to-rx transient I see with my B200mini. My thought is that the transient is slow (looks like a DC offset) and may create a false peak when part of it is convolved with the reference sync sequence. Anyway, implementing #2 made that problem go away.

The other thought I have for my particular application is to disabled the Correlation Estimator (CE) when I know there will be no sync sequence. Since I have a TDMA system with a GPSDO/clock governing the slot scheme, I can generate an ?enable? pulse from my MAC and use it to control the CE block.

The big flaw with my approach in 1) and 2) is that I am not accounting for variable receive power such as you?d expect in a multi-radio TDMA system? first things first, though, gotta see packets received reliably under Tx constant power.

Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen

Der entscheidende Augenblick der menschlichen Entwicklung ist immerw?hrend. Darum sind die revolution?ren geistigen Bewegungen, welche alles Fr?here f?r nichtig erkl?ren, im Recht, denn es ist noch nichts geschehen. - Franz Kafka

On Oct 4, 2016, at 13:31, devin kelly <address@hidden> wrote:

Steven,

I've had the exact same problem as you - my flowgraphs from 3.7.9 worked well but now I'm getting a lot of false detections from this block.

Is this really how this block is supposed to perform? We just have to use trial and error to find the right threshold?

Thanks For Any Help,
Devin

On Tue, Sep 27, 2016 at 11:37 AM, Steven Knudsen <address@hidden <mailto:address@hidden>> wrote:
Alright, after some more thought I believe I understand what is going on.

By looking at the cross-correlation power for the current input samples, the threshold can be calculated as a desired false alarm rate. An ?arbitrary? threshold can be set independently of the received signal power.

Unfortunately, for the test_corr_est.grc example, you just can?t set the threshold high enough to avoid false alarms. I tried the CE block with up to 0.999999 for the threshold and it was still a mess, though much better.

That said, for my own application/flowgraph, setting the CE block threshold to 0.9999 appears to work. I can set as ?low? as 0.999, but that?s it.

This makes me wonder why bother to have a threshold parameter at all? Maybe just set the calculated d_pfa value to 10 or something and be done with it. Of course, we all hate magic numbers, and so doing would introduce a second number to the algorithm (the first is a multiplier of 4 in the peak thresholding logic).

Thanks for your patience?

Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca <http://techconficio.ca/>
www.linkedin.com/in/knudstevenknudsen <http://www.linkedin.com/in/knudstevenknudsen>

Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt ist zu erreichen. - Franz Kafka

Begin forwarded message:

From: Steven Knudsen <address@hidden <mailto:address@hidden>>
Subject: Correlation Estimator in 3.7.10
Date: September 27, 2016 at 07:40:17 MDT
To: GNURadio Discussion List <address@hidden <mailto:address@hiddenorg>>
Cc: Knud <address@hidden <mailto:address@hidden>>

Hi All,

I am pretty confused with some of the changes to the corr_est_cc_impl.cc threshold detection algorithm.

Previously, in _set_threshold(), the zero-offset autocorrelation of the reference symbols was computed and scaled by the desired relative threshold when the correlation estimator is instantiated to provide a fixed (constant for the run) threshold (d_thresh). That makes sense to me and appeared to work pretty well.

Now, in _set_threshold(), a XXXX is calculated as d_pfa = -logf(1.0f - threshold) . In the work function, the detection threshold is calculated anew on each invocation as the mean value of the square of the current correlation of the reference symbols with the input symbols, scaled by d_pfa.

How can the threshold for detecting the peak of the correlation against the reference symbols be a function of the input symbols? I know that using an absolute threshold based on only the reference symbols may be a problem because you can?t know the magnitude of the received input symbols, but I think that?s why there is a block callback for set_threshold().

The net result is that when one runs the correlation estimator, a bunch of peaks are output in the vicinity of the sync sequence in the input stream. The test_corr_est.grc example in gr-digital shows this well.

I checked the commit history and the only relevant comment is ?Works with arbitrary scaling?. This suggests that the changes are meant to include in the threshold the effect of arbitrary input signal power, which does make some sense. Again, I thought that was why there was a callback, but even that is clunky and I could be wrong.

Anyway, all I know is that the correlation estimator used to work really well for me and is now, in my applications, broken badly. Maybe I?m not setting it up correctly, but AFAIK the block parameters are the same.

Thanks for your consideration of this question,

steven

Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca <http://techconficio.ca/>
www.linkedin.com/in/knudstevenknudsen <http://www.linkedin.com/in/knudstevenknudsen>

All the wires are cut, my friends
Live beyond the severed ends. Louis MacNeice

_______________________________________________
Discuss-gnuradio mailing list
address@hidden <mailto:address@hiddenorg>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio <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/20161004/5a23c534/attachment.html>

------------------------------

Message: 6
Date: Tue, 04 Oct 2016 13:23:20 -0700
From: "Chad M. Spooner" <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install problems
Message-ID: <6d5eae41623e096d2aab488dfe857address@hidden>
Content-Type: text/plain; charset="us-ascii"

Forum:

I'm trying to get gnuradio/UHD up on a CentOS 7 machine. I've made a lot
of progress, but have a problem I can't understand.

I'll provide details below, but the error message is obtained during the
attempted installation of wxpython. It is a compiler error. The first
error that appears is:

---------------------------------------------------------------------------

/usr/local/gnuradio/src/wxpython/bk-deps g++ -c -o coredll_imagpng.o
-I./.pch/wxprec_coredll -D__WXGTK__ -DWXBUILDING -I./src/tiff
-I./src/jpeg -DWXUSINGDLL -DWXMAKINGDLL_CORE -DwxUSE_BASE=0 -fPIC -DPIC
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-I/usr/local/gnuradio/src/wxpython/lib/wx/include/gtk2-ansi-release-2.8
-I./include -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15
-I/usr/include/libdrm -I/usr/include/harfbuzz -DWX_PRECOMP -pthread
-Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing
./src/common/imagpng.cpp
./src/common/imagpng.cpp: In member function 'virtual bool
wxPNGHandler::LoadFile(wxImage*, wxInputStream&, bool, int)':
./src/common/imagpng.cpp:532:30: error: 'voidp' was not declared in this
scope
(voidp) NULL,
^

-------------------------------------------------------------------------------------------

Machine: HP Z Book G3 running CentOS 7, kernel
3.10.0-327.36.1.el7.x86_64 #1 SMP.

PyBOMBS: Version 2.2.0

Python: Version 3.5.2

pip: pip 8.1.2 from /usr/local/lib/python3.5/site-packages (python 3.5)

gcc: gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)

Here is the command line I used to try to install gnuradio and UHD:

pybombs prefix init /usr/local/gnuradio -a gnuradio -R gnuradio-default

I've attached the full text log of what appeared on the screen after I
issued that command.

(I've got UHD running under Ubuntu 16.04 and Fedora Core 24, but since
CentOS is residing on a very fast SSD and I need fast I/O, I was hoping
to get UHD (at least) going on CentOS too.)

Thanks for any advice anybody might have.

Chad

--
Chad M. Spooner, PhD
NorthWest Research Associates
301 Webster Street
Monterey, CA 93940
address@hidden
cell: (831) 521 6743
office: (831) 582 4904
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20161004/b19a4ad4/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnuradio_uhd_install_log.txt
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20161004/b19a4ad4/attachment.txt>

------------------------------

Message: 7
Date: Tue, 4 Oct 2016 13:56:41 -0700
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install
    problems
Message-ID: <d732bd83-d095-ef55-f32d-address@hidden>
Content-Type: text/plain; charset="windows-1252"

Hi Chad,

the question I'd ask here is:
Do you *really* need WxGUI support? It's going away with GNU Radio 3.8,
and if you remove the Wx dependency from the GNU Radio package, GNU
Radio will build just as well, but you'll only be presented with the
actively maintained QtGUI.

Best regards,

Marcus

On 10/04/2016 01:23 PM, Chad M. Spooner wrote:

Forum:

I'm trying to get gnuradio/UHD up on a CentOS 7 machine. I've made a
lot of progress, but have a problem I can't understand.

I'll provide details below, but the error message is obtained during
the attempted installation of wxpython. It is a compiler error. The
first error that appears is:

---------------------------------------------------------------------------

/usr/local/gnuradio/src/wxpython/bk-deps g++ -c -o coredll_imagpng.o
-I./.pch/wxprec_coredll -D__WXGTK__ -DWXBUILDING -I./src/tiff
-I./src/jpeg -DWXUSINGDLL -DWXMAKINGDLL_CORE -DwxUSE_BASE=0 -fPIC
-DPIC -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-I/usr/local/gnuradio/src/wxpython/lib/wx/include/gtk2-ansi-release-2.8
-I./include -pthread -I/usr/include/gtk-2.0
-I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/libdrm
-I/usr/include/harfbuzz -DWX_PRECOMP -pthread -Wall -Wundef
-Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing ./src/common/imagpng.cpp
./src/common/imagpng.cpp: In member function ?virtual bool
wxPNGHandler::LoadFile(wxImage*, wxInputStream&, bool, int)?:
./src/common/imagpng.cpp:532:30: error: ?voidp? was not declared in
this scope
(voidp) NULL,
^

-------------------------------------------------------------------------------------------

Machine: HP Z Book G3 running CentOS 7,
kernel 3.10.0-327.36.1.el7.x86_64 #1 SMP.

PyBOMBS: Version 2.2.0

Python: Version 3.5.2

pip: pip 8.1.2 from /usr/local/lib/python3.5/site-packages (python 3.5)

gcc: gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)

Here is the command line I used to try to install gnuradio and UHD:

pybombs prefix init /usr/local/gnuradio -a gnuradio -R gnuradio-default

I've attached the full text log of what appeared on the screen after I
issued that command.

(I've got UHD running under Ubuntu 16.04 and Fedora Core 24, but since
CentOS is residing on a very fast SSD and I need fast I/O, I was
hoping to get UHD (at least) going on CentOS too.)

Thanks for any advice anybody might have.

Chad

--
Chad M. Spooner, PhD
NorthWest Research Associates
301 Webster Street
Monterey, CA 93940
address@hidden <mailto:address@hidden>
cell: (831) 521 6743
office: (831) 582 4904

_______________________________________________
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/20161004/19dd5a6c/attachment.html>

------------------------------

Message: 8
Date: Tue, 4 Oct 2016 14:25:19 -0700
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install
    problems
Message-ID: <e5b13b32-0d30-e584-226e-address@hidden>
Content-Type: text/plain; charset=windows-1252

PyBOMBS doesn't have an easy way of telling it that you don't need WxGUI
if you're building from a prefix recipe (i.e., -R gnuradio-default).
I'm not sure why WX doesn't compile on CentOS 7, but if it fails, it'll
take down your PyBOMBS build. Since the whole point of PyBOMBS is to
take all the installation pain away, this is definitely an issue.

I've flagged wxpython as optional in gnuradio-default and
gnuradio-stable. If you run
$ pybombs recipes update

you should get the new versions and a failing WX won't crash your build.

Cheers,
Martin

On 10/04/2016 01:56 PM, Marcus M?ller wrote:
Hi Chad,

the question I'd ask here is:
Do you *really* need WxGUI support? It's going away with GNU Radio 3.8,
and if you remove the Wx dependency from the GNU Radio package, GNU
Radio will build just as well, but you'll only be presented with the
actively maintained QtGUI.

Best regards,

Marcus

On 10/04/2016 01:23 PM, Chad M. Spooner wrote:

Forum:

I'm trying to get gnuradio/UHD up on a CentOS 7 machine. I've made a
lot of progress, but have a problem I can't understand.

I'll provide details below, but the error message is obtained during
the attempted installation of wxpython. It is a compiler error. The
first error that appears is:

---------------------------------------------------------------------------

/usr/local/gnuradio/src/wxpython/bk-deps g++ -c -o coredll_imagpng.o
-I./.pch/wxprec_coredll -D__WXGTK__ -DWXBUILDING -I./src/tiff
-I./src/jpeg -DWXUSINGDLL -DWXMAKINGDLL_CORE -DwxUSE_BASE=0 -fPIC
-DPIC -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-I/usr/local/gnuradio/src/wxpython/lib/wx/include/gtk2-ansi-release-2.8 -I./include
-pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng15 -I/usr/include/libdrm -I/usr/include/harfbuzz
-DWX_PRECOMP -pthread -Wall -Wundef -Wno-ctor-dtor-privacy -O2
-fno-strict-aliasing ./src/common/imagpng.cpp
./src/common/imagpng.cpp: In member function ?virtual bool
wxPNGHandler::LoadFile(wxImage*, wxInputStream&, bool, int)?:
./src/common/imagpng.cpp:532:30: error: ?voidp? was not declared in
this scope
(voidp) NULL,
^

-------------------------------------------------------------------------------------------

Machine: HP Z Book G3 running CentOS 7,
kernel 3.10.0-327.36.1.el7.x86_64 #1 SMP.

PyBOMBS: Version 2.2.0

Python: Version 3.5.2

pip: pip 8.1.2 from /usr/local/lib/python3.5/site-packages (python 3.5)

gcc: gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)

Here is the command line I used to try to install gnuradio and UHD:

pybombs prefix init /usr/local/gnuradio -a gnuradio -R gnuradio-default

I've attached the full text log of what appeared on the screen after I
issued that command.

(I've got UHD running under Ubuntu 16.04 and Fedora Core 24, but since
CentOS is residing on a very fast SSD and I need fast I/O, I was
hoping to get UHD (at least) going on CentOS too.)

Thanks for any advice anybody might have.

Chad

--
Chad M. Spooner, PhD
NorthWest Research Associates
301 Webster Street
Monterey, CA 93940
address@hidden <mailto:address@hidden>
cell: (831) 521 6743
office: (831) 582 4904

_______________________________________________
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

------------------------------

Subject: Digest Footer

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

------------------------------

End of Discuss-gnuradio Digest, Vol 167, Issue 5
************************************************

--

Chad M. Spooner, PhD
NorthWest Research Associates
301 Webster Street
Monterey, CA 93940
address@hidden
cell: (831) 521 6743
office: (831) 582 4904
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Chad M. Spooner NorthWest Research Associates 301 Webster Street Monterey, CA 93940 address@hidden 831 582 4904
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

From:	Anon Lister
Subject:	Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install problems
Date:	Fri, 7 Oct 2016 16:07:04 -0400