search

DUNE-DAQ / daq-release

Scripts and configuration files for the DUNE DAQ release
https://dune-daq-sw.readthedocs.io/en/latest/packages/daq-release/
2 stars 0 forks source link

Protobuf linking issues #347

Closed mroda88 closed 6 months ago

mroda88 commented 6 months ago

Description of the problem

I am having problems in using some non-trivial functions of ProtoBuf. With non-trivial here I mean functions which are not generated through a schema, but are native of the protobuf core package. It seems they are mostly related to accessing (both read and write) dynamic allocated memory. When used, they cause linking problems. Something like 

/cvmfs/dunedaq.opensciencegrid.org/spack/externals/ext-v2.0/spack-0.20.0-gcc-12.1.0/spack-0.20.0/opt/spack/linux-almalinux9-x86_64/gcc-12.1.0/binutils-2.40-cqwtqfjw7u2f6b75f3qfpyiju2qjdrzo/bin/ld: opmonlib/CMakeFiles/schema_conversion_test.dir/unittest/schema_conversion_test.cxx.o: undefined reference to symbol '_ZN4absl12lts_2023012512log_internal17MakeCheckOpStringImmEEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEET_T0_PKc'
/cvmfs/dunedaq.opensciencegrid.org/spack/externals/ext-v2.0/spack-0.20.0-gcc-12.1.0/spack-0.20.0/opt/spack/linux-almalinux9-x86_64/gcc-12.1.0/binutils-2.40-cqwtqfjw7u2f6b75f3qfpyiju2qjdrzo/bin/ld: /cvmfs/dunedaq.opensciencegrid.org/spack/externals/ext-v2.0/spack-0.20.0-gcc-12.1.0/spack-0.20.0/opt/spack/linux-almalinux9-x86_64/gcc-12.1.0/abseil-cpp-20230125.3-tti6ovtntqy4rvp2y43py6tyc2qdyvpi/lib64/libabsl_log_internal_check_op.so.2301.0.0: error adding symbols: DSO missing from command line

It seems that when the function is used in a source file compiled calling daq_add_library and the library is linked, all is well. The problem appears when the function is used in an application daq_add_application or in a unit test generated with daq_add_unit_test. I haven't tested yet with plugins.

The general feeling is that something is really unstable. The concern here is that when the new monitoring system based on protobuf will be used everywhere, this might cause a number of issues all over the place. So I would like to try to sort this out before that, if possible. Or at least, trying to understand possible solutions or practices that avoid the problem but allows us to do all that protobuf promises.

How to reproduce it

To reproduce the problem, I would recommend to use this commit https://github.com/DUNE-DAQ/opmonlib/tree/5033ec15e28f84ad68c1af9efd0af68fcc63d88c of opmonlib. Build a new development area, having locally opmonlib and its necessary dependencies. The commit compiles correctly.

To reproduce the problem, you can decomment any of the following lines https://github.com/DUNE-DAQ/opmonlib/blob/5033ec15e28f84ad68c1af9efd0af68fcc63d88c/unittest/schema_conversion_test.cxx#L58 or https://github.com/DUNE-DAQ/opmonlib/blob/5033ec15e28f84ad68c1af9efd0af68fcc63d88c/unittest/schema_conversion_test.cxx#L42. And then recompile. You will have different linking errors, as they point to different missing functions. But I think the cause is the same.

As you can see both are used to access dynamic memory. The first access a map, the second extends a vector. Both are the protobuf versions of the containers, not the STL containers.

Some further details

What is puzzling is the following. The very same unittest, it's calling indirectly calling a map access https://github.com/DUNE-DAQ/opmonlib/blob/5033ec15e28f84ad68c1af9efd0af68fcc63d88c/src/Utils.cpp#L65 and it works. Simply because the function is not called directly by the unittest. So I'm fairly confident that the libraries are at least linked correctly in the library. In fact the problematic line of the unittest, line 58, could be replaced exactly with the line in the library

auto final_int =  (*test_entry.mutable_data())["int_example"].int8_value();

to get the linking error.

jcfreeman2 commented 6 months ago

Solved in opmonlib as described in https://github.com/DUNE-DAQ/opmonlib/pull/26