ilo2_ribcl needs to have access to signal_service_thread

[openhpi2]

ilo2_ribcl plugin uses signal_service_thread variable which is in daemon code. This code is not a library and it is not linked against ilo2_ribcl plugin library. This is not a big problem as ilo2_ribcl is a plugin. But ideally the library containing the variable needs to be linked against the ilo2_ribcl. However openhpid is the daemon application. Please take a look at how to handle it.

Reported by: dr_mohan

[openhpi2]

• assigned_to: Praveen

Original comment by: dr_mohan

[openhpi2]

dh_shlibdeps -a -- -- warnings=1
is run at the debian packaging stage. It returns the following warning message as the libilo2_ribcl.so.* contains signal_service_thread which is not resolvable within the library.

pkg-shlibdeps: warning: debian/openhpi-plugin-ilo2-ribcl/usr/lib/openhpi/libilo2_ribcl.so.3.6.1 contains an unresolvable reference to symbol signal_service_thread: it's probably a plugin

This is not a major problem as ilo2_ribcl is a plugin and the daemon libraries are present. So we do not want to add a new dependency. Looking at the code, daemon and the plugin code are mixed up in this case as this variable is used inside the plugin thread (not a thread created by main thread). Take a deeper look at how to handle the functionality without adding this new variable. May be the main ilo2_ribcl thread could signal the other ilo2_ribcl threads? Take a deeper look at this.

Original comment by: dr_mohan

[openhpi2]

mkdir /home/mohan/debian_testing_test
cd /home/mohan/debian_testing_test

Go to https://packages.debian.org/testing/libopenhpi3 and download three files manually
They are openhpi_3.6.1-2.debian.tar.xz, openhpi_3.6.1-2.dsc and openhpi_3.6.1.orig.tar.gz

dpkg-source -x openhpi_3.6.1-2.dsc 2>&1 | tee dpkg_source.log
cd openhpi-3.6.1
debuild -uc -us 2>&1 | tee ../debuild.log
vi ../debuild.log and look for signal_service_thread

Original comment by: dr_mohan