gr4 build error

Happy Monday GR citizens, hope this day finds you well.

not seeing where that -R option is being added...

[192/198] Linking CXX shared library blocks/http/libGr4HttpBlocksPlugin.so
FAILED: blocks/http/libGr4HttpBlocksPlugin.so
: && /opt/gcc-16.2.0/bin/c++ -fPIC   -shared -R/usr/lib64 -Wl,-soname,libGr4HttpBlocksPlugin.so -o blocks/http/libGr4HttpBlocksPlugin.so blocks/http/CMakeFiles/Gr4HttpBlocks.dir/__/__/generated_plugins/http/integrator.cpp.o blocks/http/CMakeFiles/Gr4HttpBlocks.dir/__/__/generated_plugins/http/plugin_entry.cpp.o blocks/http/CMakeFiles/Gr4HttpBlocks.dir/__/__/generated_plugins/http/HttpTimeSeriesSink_0_0.cpp.o blocks/http/CMakeFiles/Gr4HttpBlocks.dir/__/__/generated_plugins/http/HttpTimeSeriesSink_0_1.cpp.o  -Wl,-rpath,/usr/steve/gnuradio4/install/lib:  /usr/steve/gnuradio4/install/lib/libgnuradio-core.a  /usr/steve/gnuradio4/install/lib/libgnuradio-blocklib-core.so  /usr/steve/gnuradio4/install/lib/libgnuradio-plugin.so  /usr/lib64/libz.so  /usr/lib64/libssl.so  /usr/lib64/libcrypto.so  /usr/lib64/libbrotlicommon.so  /usr/lib64/libbrotlidec.so  /usr/lib64/libbrotlienc.so && :
c++: error: unrecognized command-line option '-R'

--

If something is requisite, how can it possibly be, prerequisite? 

vanitas vanitatum omnia vanitas
later, steve
http://umn.edu/~barbo

New gRPC/Protobuf dependency in the next UHD release (4.11.0) — packaging guidance

Hi all,

 

Starting with the next official UHD release (4.11.0), UHD's MPM RPC transport is migrating from mprpc (msgpack-RPC)
to gRPC/Protobuf. This affects packaging for any distribution that builds UHD with MPM device support
(ENABLE_MPMD=ON, the default), i.e., support for N3xx, E3xx, and X4xx devices. We wanted to provide an early,
consolidated summary so you can plan your recipes/spec files accordingly.

 

1. Minimum gRPC/Protobuf versions

We track recommended minimum versions in UHDMinDepVersions.cmake:

Library	Minimum version
gRPC	1.3
Protobuf	3.12

 

These minimum versions are based on the oldest validated distribution in our CI matrix: Ubuntu 22.04 (Jammy).
Any recent gRPC/Protobuf version from your distribution package manager should also work.

 

Note: On Windows, adding gRPC as vcpkg dependency has significantly increased vcpkg triplet build time and cache sizes.

 

2. Full dependency breakdown

Build-time (source builds only):

Package name (Debian/Ubuntu)	Package name (Fedora)	Role
libgrpc++-dev	grpc-devel	gRPC C++ dev headers & libraries
libprotobuf-dev	protobuf-devel	Protobuf C++ dev headers & libraries
protobuf-compiler	protobuf-compiler	protoc compiler
protobuf-compiler-grpc	grpc-plugins	grpc_cpp_plugin — gRPC C++ codegen plugin

 

Runtime (needed by installed UHD, including binary installer users):

Package name (Debian/Ubuntu)	Package name (Fedora)	Role
libgrpc++<ver>	grpc	gRPC C++ runtime shared library
libprotobuf<ver>	protobuf	Protobuf runtime shared library
python3-grpcio	python3-grpcio	Python gRPC runtime

 

Note: The Python grpcio module is required only for the MPM simulator. The simulator is built on the host system
             and installed into the UHD Python path, where it imports the Python grpc module.

 

3. Distro-specific integration notes:

Linux:

CMake discovery: UHD ships with a FindgRPC.cmake module that first attempts to use gRPC's
CMake CONFIG package (available on Ubuntu 24.04+, Fedora 38+, and via vcpkg). It then falls back to
pkg-config for older distributions (such as Ubuntu 22.04), where libgrpc++-dev does not provide CMake
configuration files.Both CMake-config and pkg-config-only environments are supported.

 

Windows:

There are no prebuilt distro packages; gRPC and Protobuf must be built from source or
installed through a package manager (we use vcpkg). Working examples are documented in the 
UHD build instructions in the UHD manual.

 

4. Integration support

We're happy to help you land this cleanly.

Please reach out with any questions. And let us know if there are packaging constraints on your side that we should be aware of before the release.

 

Regards,

 

Marian Koop

on behalf of the UHD Maintainers

 

Marian Koop (he/him/his) Principal Software Engineer SDR & RFmx Test & Measurement Group

 

 

 

Changes to files.ettus.com

Please be advised that the hosting service for "files.ettus.com" has migrated to a new service provider.  The URL "https://files.ettus.com" remains the same, and the URLs for all the currently hosted files are also unchanged.  Extensive regression testing was performed to ensure proper operation with all the UHD tooling and utility programs, such as "uhd_images_downloader", so there should be minimal impact on end-users.  If you experience any problems, or have any questions, please email me at "neel.pandeya@ettus.com".

--Neel Pandeya

Re: function probes don't work in hierarchical blocks

Hi Eugene, > How would you display the current state (e.g. mean > power from a probe mag^2) your use case sounds very straightforward: use the QT GUI Number Sink. But as explained in my previous email: just write the logic you need. (we might want to wrap this in an off-the-shelf block). I'm attaching a flow graph with three options to solve your problem, on the right half of the flowgraph, top to bottom: 1. straightforward number sink 2. a minimal python block that counts to N items, then emits a message containing the value at that position, repeats 3. a minimal python block that, triggered on an external message, emits the last value as message. To display a message's content, you can use the QT GUI Message Edit Box in "static" mode. Note that you can generate the triggers for the third option inside your hier block (as I'm doing here with the Message Strobe), or use a "Pad Source" to allow the user of your block to trigger externally (for example, manually with a Qt GUI Msg Push Button). Added a disabled Pad Source to clarify that concept. > or probe_rate Probe Rate produces messages. I personally mostly connect that to a Message Debug's Log port and read the console. But I can see where you're coming from! You can write a python block with a input message port with a handler. (see the message-triggered from above for an example). The block would furhtermore have an output message port, and no stream in- our outputs. The handler would do something like def msg_handler(self, msg): self.message_port_pub(self._msport_out, pmt.dict_ref(msg, pmt.mp("rate_now"), pmt.from_float(0.0))) to convert from the dictionary that Probe Rate emits to the rate now message. We might also want a ready-made block that does that for you in general. Best, Marcus

Re: function probes don't work in hierarchical blocks

Maybe I am missing something basic.  How would you display the current state (e.g. mean power from a probe mag^2) or probe_rate in the GUI w/out a function probe?  I create a probe to call level() and then display it as a label.  

Eugene Grayver, Ph.D.

Principal Engineer

310-336-1274

Re: GRC file sink/source name does not honor variables

Oops, that was my mistake!  I left off the quotation marks.

Eugene Grayver, Ph.D.

Principal Engineer

310-336-1274

Re: function probes don't work in hierarchical blocks

Hi Eugene, agreed, that's a bit ugly. Unless someone comes up with a very non-intrusive and prettier solution, I'll propose we'll leave it as is: Function Probes are an ugly hack, that has, over the course of time, caused more harm than good. If you need to probe a signal at regular intervals from a sample stream¹, you should probably properly decimate (i.e., low-pass filter with decimation >> 1) or just keep 1-in-N instead. If you really need "random times relative to sample processing, but time controlled by the asynchronous reality of the computer around it", then sending messages into a python block's "trigger" input message port, and that block then sending a (sample index, value) tuple out a "value" message port would solve the same issue, but in a way that's compatible with hier blocks. (subliminal message here: don't rely on function probes. I have not *once* found a good use case for them.) Best regards, Marcus ¹ don't forget that GNU Radio blocks always process samples in larger chunks, so "wall-clock time" has, at best, usually not at all, a very loose relation to signal being probed On 2026-07-21 6:40 PM, Eugene Grayver wrote: > Functions probes don't work in hierarchical blocks. > A function probe generates a thread body such as: > > ------- >         def _cross_freq_estimate_probe(): >           self.flowgraph_started.wait() >           while True: > >             val = self.cross_freq_probe.level() > ------- > > However, hierarchical blocks don't have a member flowgraph_started.  I don't have a simple > suggestion, but perhaps we can pass this member from the parent?  A bit ugly!  Makes the > hier blocks dependent on the rest of the GRC framework — i.e. can't easily reuse in > python-only design flow. > > > Eugene Grayver, Ph.D. > Principal Engineer > 310-336-1274