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" <cmspoo...@nwra.com> 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, discuss-gnuradio-requ...@gnu.org wrote: > > Send Discuss-gnuradio mailing list submissions to > discuss-gnuradio@gnu.org > > 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-requ...@gnu.org > > You can reach the person managing the list at > discuss-gnuradio-ow...@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 <damindra.band...@gmail.com> > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] Replacement for packet encoder/decoder > Message-ID: > <CANpceN-aihkrnJuFMbwr9a2J9XyA=b-kyhsm28ouocdxux5...@mail.gmail.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 <marcus.muel...@ettus.com> > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Block Thread question > Message-ID: <8518d7c5-bb52-b44a-df51-eed2e8068...@ettus.com> > 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 > Discuss-gnuradio@gnu.org > 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" <garv...@gatech.edu> > To: Marcus M?ller <marcus.muel...@ettus.com> > Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> > Subject: Re: [Discuss-gnuradio] Block Thread question > Message-ID: <9707d576-16c7-427d-9ac9-205776100...@gatech.edu> > 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 <marcus.muel...@ettus.com< > mailto:marcus.muel...@ettus.com>> 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 > Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> > 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 <dwwke...@gmail.com> > To: Steven Knudsen <ee.k...@gmail.com> > Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org>, Knud > <k...@ieee.org> > Subject: Re: [Discuss-gnuradio] Fwd: Correlation Estimator in 3.7.10 > Message-ID: > <caanlyuywhz6ydbfpprfb_zhez6awapecsr9aqfkdxg_dr69...@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 <ee.k...@gmail.com> > 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 <ee.k...@gmail.com> > *Subject: **Correlation Estimator in 3.7.10* > *Date: *September 27, 2016 at 07:40:17 MDT > *To: *GNURadio Discussion List <discuss-gnuradio@gnu.org> > *Cc: *Knud <k...@ieee.org> > > 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 > Discuss-gnuradio@gnu.org > 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 <ee.k...@gmail.com> > To: devin kelly <dwwke...@gmail.com> > Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org> > Subject: Re: [Discuss-gnuradio] Fwd: Correlation Estimator in 3.7.10 > Message-ID: <2b4339a2-c07b-42ef-835c-b6c874446...@gmail.com> > 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 <dwwke...@gmail.com> 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 <ee.k...@gmail.com > <mailto:ee.k...@gmail.com>> 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 <ee.k...@gmail.com <mailto:ee.k...@gmail.com>> > Subject: Correlation Estimator in 3.7.10 > Date: September 27, 2016 at 07:40:17 MDT > To: GNURadio Discussion List <discuss-gnuradio@gnu.org <mailto: > discuss-gnuradio@gnu.org>> > Cc: Knud <k...@ieee.org <mailto:k...@ieee.org>> > > 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 > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > 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" <cmspoo...@nwra.com> > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install problems > Message-ID: <6d5eae41623e096d2aab488dfe857...@nwra.com> > 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 > cmspoo...@nwra.com > 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 <marcus.muel...@ettus.com> > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install > problems > Message-ID: <d732bd83-d095-ef55-f32d-239799f4a...@ettus.com> > 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 > cmspoo...@nwra.com <mailto:cmspoo...@nwra.com> > cell: (831) 521 6743 > office: (831) 582 4904 > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > 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 <martin.br...@ettus.com> > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install > problems > Message-ID: <e5b13b32-0d30-e584-226e-167a29d87...@ettus.com> > 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 > cmspoo...@nwra.com <mailto:cmspoo...@nwra.com> > cell: (831) 521 6743 > office: (831) 582 4904 > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > 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 > cmspoo...@nwra.com > cell: (831) 521 6743 > office: (831) 582 4904 > > _______________________________________________ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- > > Chad M. Spooner NorthWest Research Associates 301 Webster Street Monterey, > CA 93940 cmspoo...@nwra.com 831 582 4904 > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
