unable to build 20.04.01 on gcc 9

[ZeroChaos-]

This fails pretty late in the output so I trimmed it to what I believe matters. If you want more, or all, of the output please just let me know. This is separate and distinct from my build failure in issue #526 , as that build failure looks like a common gcc-10 build failure and this failure is different and while using gcc 9. I have replicated this failure using a version from git as well.

[559/602] : && /usr/bin/cmake -E remove srsenb/src/stack/upper/libsrsenb_upper.a && /usr/bin/x86_64-pc-linux-gnu-ar qc srsenb/src/stack/upper/libsrsenb_upper.a  srsenb/src/stack/upper/CMakeFiles/srsenb_upper.dir/gtpu.cc.o srsenb/src/stack/upper/CMakeFiles/srsenb_upper.dir/pdcp.cc.o srsenb/src/stack/upper/CMakeFiles/srsenb_upper.dir/rlc.cc.o srsenb/src/stack/upper/CMakeFiles/srsenb_upper.dir/s1ap.cc.o && /usr/bin/x86_64-pc-linux-gnu-ranlib srsenb/src/stack/upper/libsrsenb_upper.a && :
[560/602] : && /usr/bin/x86_64-pc-linux-gnu-g++  -Os -march=native -mtune=native -pipe -frecord-gcc-switches -Wall -Wno-comment -Wno-reorder -Wno-unused-variable -Wtype-limits -std=c++11 -Wno-unused-but-set-variable -march=native -mfpmath=sse -mavx2 -DLV_HAVE_AVX2 -DLV_HAVE_AVX -DLV_HAVE_SSE -fvisibility=hidden -O3 -fno-trapping-math -fno-math-errno -DBUILD_TYPE_RELEASE -fdiagnostics-color=always  -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0    -rdynamic srsenb/src/CMakeFiles/srsenb.dir/main.cc.o srsenb/src/CMakeFiles/srsenb.dir/enb.cc.o srsenb/src/CMakeFiles/srsenb.dir/metrics_stdout.cc.o srsenb/src/CMakeFiles/srsenb.dir/metrics_csv.cc.o  -o srsenb/src/srsenb  -Wl,-rpath,/var/tmp/portage/net-wireless/srslte-20.04.1/work/srslte-20.04.1_build/srsenb/src:/var/tmp/portage/net-wireless/srslte-20.04.1/work/srslte-20.04.1_build/lib/src/phy/rf:  srsenb/src/phy/libsrsenb_phy.a  srsenb/src/stack/libsrsenb_stack.a  srsenb/src/stack/upper/libsrsenb_upper.a  srsenb/src/stack/mac/libsrsenb_mac.a  srsenb/src/stack/rrc/libsrsenb_rrc.a  lib/src/common/libsrslte_common.a  lib/src/mac/libsrslte_mac.a  lib/src/phy/libsrslte_phy.a  lib/src/upper/libsrslte_upper.a  lib/src/radio/libsrslte_radio.a  lib/src/asn1/librrc_asn1.a  lib/src/asn1/libs1ap_asn1.a  srsenb/src/libenb_cfg_parser.so  -lpthread  -lboost_program_options-mt  -lmbedcrypto  -lconfig++  -lsctp  lib/src/asn1/libsrslte_asn1.a  lib/src/phy/rf/libsrslte_rf.so  lib/src/phy/rf/libsrslte_rf_utils.a  -luhd  -lbladeRF  -lSoapySDR  -lzmq  lib/src/asn1/libasn1_utils.a  lib/src/common/libsrslte_common.a  lib/src/phy/libsrslte_phy.a  -lpthread  -lm  -lfftw3f  -lmbedcrypto && :
FAILED: srsenb/src/srsenb 
: && /usr/bin/x86_64-pc-linux-gnu-g++  -Os -march=native -mtune=native -pipe -frecord-gcc-switches -Wall -Wno-comment -Wno-reorder -Wno-unused-variable -Wtype-limits -std=c++11 -Wno-unused-but-set-variable -march=native -mfpmath=sse -mavx2 -DLV_HAVE_AVX2 -DLV_HAVE_AVX -DLV_HAVE_SSE -fvisibility=hidden -O3 -fno-trapping-math -fno-math-errno -DBUILD_TYPE_RELEASE -fdiagnostics-color=always  -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0    -rdynamic srsenb/src/CMakeFiles/srsenb.dir/main.cc.o srsenb/src/CMakeFiles/srsenb.dir/enb.cc.o srsenb/src/CMakeFiles/srsenb.dir/metrics_stdout.cc.o srsenb/src/CMakeFiles/srsenb.dir/metrics_csv.cc.o  -o srsenb/src/srsenb  -Wl,-rpath,/var/tmp/portage/net-wireless/srslte-20.04.1/work/srslte-20.04.1_build/srsenb/src:/var/tmp/portage/net-wireless/srslte-20.04.1/work/srslte-20.04.1_build/lib/src/phy/rf:  srsenb/src/phy/libsrsenb_phy.a  srsenb/src/stack/libsrsenb_stack.a  srsenb/src/stack/upper/libsrsenb_upper.a  srsenb/src/stack/mac/libsrsenb_mac.a  srsenb/src/stack/rrc/libsrsenb_rrc.a  lib/src/common/libsrslte_common.a  lib/src/mac/libsrslte_mac.a  lib/src/phy/libsrslte_phy.a  lib/src/upper/libsrslte_upper.a  lib/src/radio/libsrslte_radio.a  lib/src/asn1/librrc_asn1.a  lib/src/asn1/libs1ap_asn1.a  srsenb/src/libenb_cfg_parser.so  -lpthread  -lboost_program_options-mt  -lmbedcrypto  -lconfig++  -lsctp  lib/src/asn1/libsrslte_asn1.a  lib/src/phy/rf/libsrslte_rf.so  lib/src/phy/rf/libsrslte_rf_utils.a  -luhd  -lbladeRF  -lSoapySDR  -lzmq  lib/src/asn1/libasn1_utils.a  lib/src/common/libsrslte_common.a  lib/src/phy/libsrslte_phy.a  -lpthread  -lm  -lfftw3f  -lmbedcrypto && :
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: srsenb/src/CMakeFiles/srsenb.dir/enb.cc.o: in function `srsenb::enb::init(srsenb::all_args_t const&, srslte::logger*)':
enb.cc:(.text+0x30fc): undefined reference to `srsenb::enb_conf_sections::parse_cfg_files(srsenb::all_args_t*, srsenb::rrc_cfg_t*, srsenb::phy_cfg_t*)'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: srsenb/src/CMakeFiles/srsenb.dir/enb.cc.o: in function `srsenb::enb::parse_args(srsenb::all_args_t const&)':
enb.cc:(.text+0x7e9): undefined reference to `srsenb::enb_conf_sections::parse_cfg_files(srsenb::all_args_t*, srsenb::rrc_cfg_t*, srsenb::phy_cfg_t*)'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

[andrepuschmann]

This is also fixed in the current dev repo. I think it was just adding enb_cfg_parser to the target_link_libraries for srsenb. This happens with parallel builds, like with ninja.

[ZeroChaos-]

Just to be clear, I hit this failure with -j1. I'd be happy to test, where can I find the dev repo?

[andrepuschmann]

It's not a public repo. I'll see if we can give you access after I am back from vacation.

[ZeroChaos-]

Honestly I'd be more interested to know why it's not public than to be given private access to something I can't use. I'm shipping srslte on a livecd, private access doesn't really help me....

[andrepuschmann]

Have you tried if either PR #496 or #523 fixes your issue? Those PRs have been submitted after the 20.04.1 release and we've left them open so folks can replicate and compile srsLTE with gcc 10 before we release the next version.

[ZeroChaos-]

You can possibly understand that since these PRs were not merged that I might think the solutions in your dev tree are different. As such, what is the point? Am I going to ship srslte with random out of tree patches to hundreds of users? Am I going to test those patches and then when the next release comes out find that things are not the same? I have better things to do than test code no one is using....