Bug 245469 - comms/gnuradio gnuradio-3.8.1.0.r1 build failure
Summary: comms/gnuradio gnuradio-3.8.1.0.r1 build failure
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Yuri Victorovich
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-09 08:45 UTC by Frans van der Veer
Modified: 2020-04-13 20:41 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frans van der Veer 2020-04-09 08:45:59 UTC
The fresh released port of  gnuradio-3.8.1.0.r1 does not build:

===>   gnuradio-3.8.1.0.r1 depends on package: volk>0 - not found
===>   volk-2.2.1 depends on file: /usr/local/lib/python3.7/site-packages/mako/__init__.py - found
===>   volk-2.2.1 depends on file: /usr/local/bin/cmake - found
===>   volk-2.2.1 depends on executable: ninja - found
===>   volk-2.2.1 depends on file: /usr/local/bin/python3.7 - found
===>   volk-2.2.1 depends on shared library: liborc-0.4.so - found (/usr/local/lib/liborc-0.4.so)
===>  Configuring for volk-2.2.1
===>  Performing out-of-source build
/bin/mkdir -p /usr/ports/devel/volk/work/.build
-- Build type set to Release.
-- 
-- Python checking for python >= 3.4
-- Python checking for python >= 3.4 - found
-- 
-- Python checking for mako >= 0.4.2
-- Python checking for mako >= 0.4.2 - not found
CMake Error at CMakeLists.txt:128 (message):
  Mako templates required to build VOLK


-- Configuring incomplete, errors occurred!
See also "/usr/ports/devel/volk/work/.build/CMakeFiles/CMakeOutput.log".
See also "/usr/ports/devel/volk/work/.build/CMakeFiles/CMakeError.log".
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/devel/volk
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/comms/gnuradio
*** Error code 1

Stop.
make: stopped in /usr/ports/comms/gnuradio


The system I have is running FreeBSD:
FreeBSD arwen.f3jnet.nl. 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 GENERIC  amd64


and fully up to date with ports tree retrieved with portsnap auto:
Updating from Thu Apr  9 08:56:59 CEST 2020 to Thu Apr  9 10:00:54 CEST 2020.


Hope this is fixed soon, I'm quite a fan of Gnuradio
Comment 1 Frans van der Veer 2020-04-09 09:05:42 UTC
About mako: it is installed on the system:

root@arwen:/usr/ports/devel/volk # pkg info|grep mako
py27-mako-1.0.14               Super-fast templating language in Python
py37-mako-1.0.14               Super-fast templating language in Python

CMakeError.log for generated when building VOLK:
Performing C++ SOURCE FILE Test HAVE_CX_LIMITED_RANGE failed with the following output:
Change Dir: /usr/ports/devel/volk/work/.build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/local/bin/ninja cmTC_059e0 && [1/2] Building CXX object CMakeFiles/cmTC_059e0.dir/src.cxx.o
FAILED: CMakeFiles/cmTC_059e0.dir/src.cxx.o
/usr/bin/c++    -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DHAVE_CX_LIMITED_RANGE   -fcx-limited-range -std=gnu++11 -o CMakeFiles/cmTC_059e0.d
ir/src.cxx.o -c src.cxx
c++: error: unknown argument: '-fcx-limited-range'
ninja: build stopped: subcommand failed.


Source file was:
int main() { return 0; }
Performing C SOURCE FILE Test HAVE_C_LIMITED_RANGE failed with the following output:
Change Dir: /usr/ports/devel/volk/work/.build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/local/bin/ninja cmTC_730de && [1/2] Building C object CMakeFiles/cmTC_730de.dir/src.c.o
FAILED: CMakeFiles/cmTC_730de.dir/src.c.o
/usr/bin/cc   -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing -DHAVE_C_LIMITED_RANGE   -fcx-limited-range -std=gnu11 -o CMakeFiles/cmTC_730de.dir/s
rc.c.o   -c src.c
cc: error: unknown argument: '-fcx-limited-range'
ninja: build stopped: subcommand failed.


Source file was:
int main(void) { return 0; }
~
~
Comment 2 Frans van der Veer 2020-04-12 15:21:14 UTC
After the port update to gnuradio-3.8.1.0  the problem still exists.
Comment 3 Yuri Victorovich freebsd_committer 2020-04-12 17:55:48 UTC
(In reply to Frans van der Veer from comment #2)

The central build succeeds: http://beefy6.nyi.freebsd.org/data/121amd64-default/531468/logs/gnuradio-3.8.1.0.log

How do you build: locally, in poudriere?

So you use the up-to-date ports tree?

The fact that it builds on the central servers means that the problem is most likely on your side. (I of course have also successfully rebuilt it before committing.)
Comment 4 Frans van der Veer 2020-04-12 20:30:06 UTC
Hello Yuri,

Thanks for the response.

Yes, I am using an up-to-date ports tree, that is, as far as I know.
Before e build, I use "portsnap auto" to get the ports tree up to the latest level.

Next, I use command "portupgrade -arR". 

This has been working to my satisfaction for a long period of time already. Sometimes a build fails, but generally you'll see another another ports update a day later which resolves the problem again.

I am not familiar with poudriere to be honest. I get the impression it is way beyond what I need, just a local build.  So I actually never gave it a good study.

I  hope there will be a solution for me to build again gnuradio from ports. I would hate to be forced back to the older package version.

Stay healthy!

Frans van der Veer
Comment 5 Yuri Victorovich freebsd_committer 2020-04-12 20:48:28 UTC
Frans,

What versions of python do you have installed?

> pkg info | grep python

There might be a mismatch of python versions in case you have multiple versions installed.

Yuri
Comment 6 Yuri Victorovich freebsd_committer 2020-04-12 21:13:24 UTC
This isn't immediately related to gnuradio, instead this appears to be a problem with python versions confusion, or some other outside reason.
Comment 7 Frans van der Veer 2020-04-12 22:23:40 UTC
Yuri,

it's python 2.7 and 3.7

pkg info|grep python
libSavitar-4.5.0               LibSavitar is a c++ implementation of 3mf loading/python bindings
py27-dnspython-1.16.0          DNS toolkit for Python
py37-SimpleSoapy-1.5.1_3       Simple pythonic wrapper for SoapySDR library
py37-SoapySDR-0.7.2            Vendor and platform neutral SDR support library (python binding)
py37-asn1crypto-1.3.0          ASN.1 library with a focus on performance and a pythonic API
py37-dnspython-1.16.0          DNS toolkit for Python
py37-libusb1-1.7.1             Pure-python wrapper for libusb-1.0
py37-mysql-connector-python-8.0.19_2 MySQL driver written in Python
py37-python-docs-theme-2018.2  Sphinx theme for the CPython docs and related projects
py37-python-fcl-0.0.12         Python bindings for the Flexible Collision Library
py37-python-tools-3.7.7_1      Supplementary tools for the Python language
py37-qt5-dbussupport-5.13.1_1  Qt event loop support for dbus-python
py37-zeroconf-0.25.0           Pure python implementation of multicast DNS service discovery
python27-2.7.17_1              Interpreted object-oriented programming language
python37-3.7.7                 Interpreted object-oriented programming language

I'm trying a python-37 reinstall now. Will take a while!
Comment 8 Frans van der Veer 2020-04-13 20:34:35 UTC
Hi Yuri,

It's definetly a Python confusion thing. Upon deletion of python27 gnuradio and underlying volk did build. Not that it solves everything for me. (gr-osmosdr does not work (need to get it raw from the pothos site to get it running) and  audio sink block returns with errors) 

To make sure this is not due to  further port inconsistencies I decided today to delete all ports and build everything I need from scratch again. Perhaps that is something I should have done few years ago already..:-) It will take a while for it all to be build.....

So, thanks for guiding me to the source of the problem. You guys are doing a great job! 

I suppose you can close this report.  

Regards,

Frans van der Veer
Comment 9 Yuri Victorovich freebsd_committer 2020-04-13 20:41:14 UTC
(In reply to Frans van der Veer from comment #8)

Thanks for your update, Frans.

I should also note that it's much harder to build things locally in the ports directory the way you do it. If you want to build packages from source - poudriere is the best way. It can cleanly build the package subset that you need the same way as the packages are built centrally without the hardships of building in the ports directory.


Best,
Yuri