Open openhpi2 opened 8 years ago
Original comment by: dr_mohan
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
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
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