comms/gnuradio: Stop setting USE_GCC=yes.

[rakuco]

Summary

USE_GCC=yes causes the build to fail on systems where clang and libc++ are used by default (see bug 202143, for example). This essentially means comms/gnuradio currently only builds on 9.x. The problem is caused by the fact that on 10.x and later boost is likely built using clang and libc++, but USE_GCC=yes forces gnuradio to be built with GCC and libstdc++. Ports r392951 mentioned USE_GCC=yes was added because "clang's builtins were conflicting with gnuradio", which does not seem to happen in my tests at least.

USES=compiler:c11 needs to be added because the build fails with base GCC (i.e. 9.x) when building a C file:

/wrkdirs/usr/ports/comms/gnuradio/work/.build/volk/lib/volk_cpu.c: In function 'i_can_has_3dnow':
/wrkdirs/usr/ports/comms/gnuradio/work/.build/volk/lib/volk_cpu.c:62: error: can't find a register in class 'BREG' while reloading 'asm'
/wrkdirs/usr/ports/comms/gnuradio/work/.build/volk/lib/volk_cpu.c:62: error: 'asm' operand has impossible constraints

Test Plan

Tested 9.3-i386, 10.1-amd64 and 11-amd64.

[db]

The problem gets *very* stupid here. It's not this easy.

What has been happening is the use of fftw introduces fortran capable libs into the mix. Programs linked with python that are loaded for gnuradio must use gcc's libgcc not our faked out libgcc/librt combo. USE_GCC = yes was my attempt to force all of gnuradio to be linked against gcc libgcc so gnuradio-companion would work.

What happens is gnuradio-companion (python2 script) starts loading python modules linked against clang which use *our* stripped down version of libgcc. Later code loaded by python (via libexec/rtld-elf) loads code linked against fortran capable libgcc. Notably we are missing quad math routines in our librt which forces a load via lib of the fortran linked gcc libgcc and it of course conflicts. We can't "forget" the already bound linking and relink.

[rakuco]

Right, the situation you've summed up is basically bug 196491 as far as I can see.

I don't use GNU Radio myself, so I'm sorry if the questions I ask sound stupid:

• Would it help if Volk was built separately from the rest of GNU Radio, so the former links against clang and the latter against GCC? Debian ships Volk separately, for example, and builds GNU Radio with -DENABLE_INTERNAL_VOLK=OFF.
• How about disabling Volk support? I see that it is at least possible from a build system perspective, but I'm not sure if other functionality will also be disabled, or if it is too important to be disabled.

[db]

In D3574#73712, @rakuco wrote:

Right, the situation you've summed up is basically bug 196491 as far as I can see.

I don't use GNU Radio myself, so I'm sorry if the questions I ask sound stupid:

• Would it help if Volk was built separately from the rest of GNU Radio, so the former links against clang and the latter against GCC? Debian ships Volk separately, for example, and builds GNU Radio with -DENABLE_INTERNAL_VOLK=OFF.
• How about disabling Volk support? I see that it is at least possible from a build system perspective, but I'm not sure if other functionality will also be disabled, or if it is too important to be disabled.

Yes and previously noted here http://lists.freebsd.org/pipermail/freebsd-ports/2015-June/099634.html

I have brought it up with the tools folks involved in FreeBSD. David Chisnall agreed that our libgcc should be fixed, though the better course of action is to add the missing quadmath routines in our libcompiler_rt

I will file a PR against the tools/compiler/library routines in FreeBSD. Obviously nothing has been done. It's not something that affects only gnuradio. ;)

[db]

Looks like I had private email exchanges about this back in June

Date: Sat, 27 Jun 2015 01:59:42 +0100
From: Andrew Turner <[e-mail]>
...
From: Andrew Turner <[e-mail]>
To: Diane Bruce <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
...
As Andrew points out

"I think the issue is libquadmath.so is linked against the wrong version
of libgcc.a. It appears to have been linked against the base copy, i.e.
libcompiler_rt.a, when it should have linked against the one provided
by gcc 4.8.

The is because compiler-rt only enables the tf symbols on arm64 as
it needs a 128-bit floating point type, and it seems clang only
provides one when it's known as long double, i.e. arm64.

Andrew
"

I think it could also be fixed with a port only patch if port gcc can be statically linked against the corresponding built libquadmath

[jbeich]

Why not convert USE_GCC into USES=compiler:gcc-c++11-lib ? It helped me once with numpy in rP378057.

[rakuco]

I've tried it in HEAD, and the build failed:

In file included from /usr/local/include/c++/v1/__functional_base:130:0,
                 from /usr/local/include/c++/v1/iterator:332,
                 from /usr/local/include/c++/v1/memory:604,
                 from /usr/local/include/c++/v1/algorithm:628,
                 from /usr/local/include/c++/v1/__bit_reference:15,
                 from /usr/local/include/c++/v1/vector:265,
                 from /wrkdirs/usr/ports/comms/gnuradio/work/gnuradio-3.7.7.1/gnuradio-runtime/include/pmt/pmt_pool.h:26,
                 from /wrkdirs/usr/ports/comms/gnuradio/work/gnuradio-3.7.7.1/gnuradio-runtime/lib/pmt/pmt_pool.cc:26:
/usr/local/include/c++/v1/__functional_base_03: In instantiation of '__typeof__ (declval<_Fp>()()) std::__1::__invoke(_Fp) [with _Fp = unsigned int (*)()]':
/usr/local/include/c++/v1/__functional_03:372:33:   required from '_Rp std::__1::__function::__func<_Fp, _Alloc, _Rp()>::operator()() [with _Fp = unsigned int (*)(); _Alloc = std::__1::allocator<unsigned int (*)()>; _Rp = long unsigned int]'
/wrkdirs/usr/ports/comms/gnuradio/work/gnuradio-3.7.7.1/gnuradio-runtime/lib/pmt/pmt_pool.cc:113:1:   required from here
/usr/local/include/c++/v1/__functional_base_03:877:1: sorry, unimplemented: mangling typeof, use decltype instead
 __invoke(_Fp __f)
 ^
/usr/local/include/c++/v1/__functional_base_03: In instantiation of '__typeof__ (declval<_Fp>()()) std::__1::__invoke(_Fp) [with _Fp = boost::thread_detail::void_fct_ptr_barrier_reseter]':
/usr/local/include/c++/v1/__functional_03:372:33:   required from '_Rp std::__1::__function::__func<_Fp, _Alloc, _Rp()>::operator()() [with _Fp = boost::thread_detail::void_fct_ptr_barrier_reseter; _Alloc = std::__1::allocator<boost::thread_detail::void_fct_ptr_barrier_reseter>; _Rp = long unsigned int]'
/wrkdirs/usr/ports/comms/gnuradio/work/gnuradio-3.7.7.1/gnuradio-runtime/lib/pmt/pmt_pool.cc:113:1:   required from here
/usr/local/include/c++/v1/__functional_base_03:877:1: sorry, unimplemented: mangling typeof, use decltype instead
/usr/local/include/c++/v1/__functional_base_03: In instantiation of '__typeof__ (declval<_Fp>()()) std::__1::__invoke(_Fp) [with _Fp = boost::thread_detail::default_barrier_reseter]':
/usr/local/include/c++/v1/__functional_03:372:33:   required from '_Rp std::__1::__function::__func<_Fp, _Alloc, _Rp()>::operator()() [with _Fp = boost::thread_detail::default_barrier_reseter; _Alloc = std::__1::allocator<boost::thread_detail::default_barrier_reseter>; _Rp = long unsigned int]'
/wrkdirs/usr/ports/comms/gnuradio/work/gnuradio-3.7.7.1/gnuradio-runtime/lib/pmt/pmt_pool.cc:113:1:   required from here
/usr/local/include/c++/v1/__functional_base_03:877:1: sorry, unimplemented: mangling typeof, use decltype instead

[db]

What happens if you compile with USE_GCC removed? Does gnuradio-companion run for you?

[rakuco]

On HEAD, it just fails to start with the same backtrace as bug 196491.

[db]

Try (assuming you are using sh or zsh etc.)
export LD_PRELOAD=/usr/local/lib/gcc48/libgcc_s.so
gnuradio-companion

does this work?

[rakuco]

Sorry, gnuradio-companion actually fails with a different error:

>>> Failure
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/gui/MainWindow.py", line 179, in new_page
    flow_graph = self._platform.get_new_flow_graph()
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/base/Platform.py", line 234, in get_new_flow_graph
    def get_new_flow_graph(self): return self.FlowGraph(platform=self)
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/python/FlowGraph.py", line 37, in __init__
    _FlowGraph.__init__(self, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/base/FlowGraph.py", line 44, in __init__
    self.import_data()
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/base/FlowGraph.py", line 285, in import_data
    self._options_block = self.get_parent().get_new_block(self, 'options')
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/base/Platform.py", line 244, in get_new_block
    def get_new_block(self, flow_graph, key): return self.Block(flow_graph, n=self._blocks_n[key])
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/base/odict.py", line 34, in __getitem__
    return self._data[key]
KeyError: 'options'

However, other binaries like uhd_fft were failing with the backtrace from bug 196491, and those did work with the LD_PRELOAD hack.

[db]

What happens if you compile with USE_GCC removed? Does gnuradio-companion run for you?

In D3574#74324, @rakuco wrote:

Sorry, gnuradio-companion actually fails with a different error:

>>> Failure
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/gui/MainWindow.py", line 179, in new_page
    flow_graph = self._platform.get_new_flow_graph()
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/base/Platform.py", line 234, in get_new_flow_graph
    def get_new_flow_graph(self): return self.FlowGraph(platform=self)
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/python/FlowGraph.py", line 37, in __init__
    _FlowGraph.__init__(self, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/base/FlowGraph.py", line 44, in __init__
    self.import_data()
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/base/FlowGraph.py", line 285, in import_data
    self._options_block = self.get_parent().get_new_block(self, 'options')
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/base/Platform.py", line 244, in get_new_block
    def get_new_block(self, flow_graph, key): return self.Block(flow_graph, n=self._blocks_n[key])
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/base/odict.py", line 34, in __getitem__
    return self._data[key]
KeyError: 'options'

However, other binaries like uhd_fft were failing with the backtrace from bug 196491, and those did work with the LD_PRELOAD hack.

It runs for me with the LD_PRELOAD on FreeBSD 11.0-CURRENT #151 r287443
I did a complete pkg update before building gnuradio. Off hand I don't know what your python failure is ;)

Nevertheless, even if you can get gnuradio-companion running with a pkg update and the LD_PRELOAD hack, all binaries + gnu radio-companion will need a LD_PRELOAD or LD_LIBRARY_PATH. Even a LD_LIBMAP or /etc/libmap.conf This is exactly what I was hoping to avoid as it is now dependent entirely on which GCC is involved.

I will be filing a bug report to tools and/or ports. There are a few different ways to fix this properly as it is not just gnuradio affected.

[db]

In /usr/ports/Mk/Uses

patch<

• fortran.mk.orig 2015-09-16 00:20:24.419637000 -0400

+++ fortran.mk 2015-09-23 17:31:19.740665000 -0400
@@ -29,8 +29,8 @@
F77= gfortran${_GCC_VER}
FC= gfortran${_GCC_VER}
FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
-FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
-LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
+#FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
+#LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \

-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin

.elif ${fortran_ARGS} == ifort
BUILD_DEPENDS+= ${LOCALBASE}/intel_fc_80/bin/ifort:${PORTSDIR}/lang/ifc

Then cd /usr/ports/math/py-numpy
make clean;make;make deinstall;make install

See if gnuradio-companion works for you then please?

A .so module compiled in the process of making the py-numpy port is producing a DT_RPATH into gcc48

elfdump -a lapack_lite.so
entry: 8

d_tag: DT_RPATH
d_val: /usr/local/lib/gcc48

This is what appears to be breaking gnuradio

[db]

Also this is not the correct fix. I'll have a look at py-numpy later. Uses/fortran.mk is not the file to modify here.

[rakuco]

Apparently this ended up being done with the update to 3.7.8 in rP398562.