gnuradio 3.8.0.0

[iMichka]

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

[iMichka]

python modules have explicit framework links
    These python extension modules were linked directly to a Python
    framework binary. They should be linked with -undefined dynamic_lookup
    instead of -lpython or -framework Python.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[Bo98]

Upstream did handle that but they removed it in 3.8.0.0: gnuradio/gnuradio@ab2fb35#diff-45856d0ec64e3d28b38f044024648892L163

[chenrui333]

FYI, also there is a new release on Feb 15
https://github.com/gnuradio/gnuradio/tree/v3.7.14.0

[iMichka]

I opened an issue upstream: gnuradio/gnuradio#3279

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[iMichka]

Upstream is looking at this, let's give them a few more days.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[warnes]

Any news on this?

[iMichka]

As long as gnuradio/gnuradio#3279 is not fixed, we can not do the upgrade. This is an upstream regression.

[icpz]

For people who wants to use brewed gnuradio temporarily, you can ship this formulae to your own tap gnuradio.rb

This formulae patches the cmake/Modules/GrPython.cmake to add dynamic_lookup ldflags.

[iMichka]

@icpz: can you submit this patch upstream? I bet they will accept it. I can also try to add your patch here: if it works we can have it directly updated here; no need for a tap.

The issues is that nobody provided a patch before, so we where waiting for anybody to fix this.

[icpz]

Here is the patch

diff --git a/cmake/Modules/GrPython.cmake b/cmake/Modules/GrPython.cmake
index fd9b7583a..388da7371 100644
--- a/cmake/Modules/GrPython.cmake
+++ b/cmake/Modules/GrPython.cmake
@@ -56,7 +56,12 @@ set(QA_PYTHON_EXECUTABLE ${QA_PYTHON_EXECUTABLE} CACHE FILEPATH "python interpre
 add_library(Python::Python INTERFACE IMPORTED)
 # Need to handle special cases where both debug and release
 # libraries are available (in form of debug;A;optimized;B) in PYTHON_LIBRARIES
-if(PYTHON_LIBRARY_DEBUG AND PYTHON_LIBRARY_RELEASE)
+if(APPLE)
+    set_target_properties(Python::Python PROPERTIES
+      INTERFACE_INCLUDE_DIRECTORIES "${PYTHON_INCLUDE_DIRS}"
+      INTERFACE_LINK_LIBRARIES "-undefined dynamic_lookup"
+      )
+elseif(PYTHON_LIBRARY_DEBUG AND PYTHON_LIBRARY_RELEASE)
     set_target_properties(Python::Python PROPERTIES
       INTERFACE_INCLUDE_DIRECTORIES "${PYTHON_INCLUDE_DIRS}"
       INTERFACE_LINK_LIBRARIES "$<$<NOT:$<CONFIG:Debug>>:${PYTHON_LIBRARY_RELEASE}>;$<$<CONFIG:Debug>:${PYTHON_LIBRARY_DEBUG}>"

I think it's a little dirty work... But I don't have time to find a better solution.

Also, there's a new audit error that I have no idea:

icpz/collection/gnuradio:
  * Files were found with references to the Homebrew shims directory.
    The offending files are:
      lib/libgnuradio-runtime.3.8.1.0.dylib
      lib/libvolk.2.0.dylib
Error: 1 problem in 1 formula detected

Seems that these dylibs links with path under /usr/local/opt