robotpkg

Do you think we should switch omniorb & omniorbpy dependency to
robotpkg source, on systems where omniorb is available but not
omniorpy ?

This is already like so, it seems (at least for python3):

ifeq (Ubuntu,${OPSYS})
PREFER.omniORB?=    $(if $(filter 3,${PYTHON_MAJOR}),robotpkg,system)
else ifeq (Debian,${OPSYS})
PREFER.omniORB?=    $(if $(filter 3,${PYTHON_MAJOR}),robotpkg,system)

At least on ubuntu 22.04, HPP packages (especially
hppmanipulationwidgetsplugin.so) link to libomniDynamic4.so.2 from
ubuntu's libomniorb4-2.

How do you check that exactly? Extracting libhpp-manipulation-corba.so from
py310-hpp-manipulation-corba and checking the dependencies says:

objdump -p ./opt/openrobots/lib/libhpp-manipulation-corba.so
...
NEEDED               libomniORB4.so.3
...
RUNPATH              /opt/openrobots/lib

Which seems correct to me (robotpkg version).

In hpp-gui:

$ apt install -qqy robotpkg-py310-qt5-hpp-gui
$ ldd /opt/openrobots/lib/gepetto-gui-plugins/hppmanipulationwidgetsplugin.so | grep found
    libomniDynamic4.so.2 => not found
    libomniORB4.so.2 => not found

That /usr/lib/x86_64-linux-gnu/libomniORB4.so.2 is available in ubuntu libomniorb4-2, while robotpkg-omniorb has /opt/openrobots/lib/libomniORB4.so.3

I think this is somehow due to the build process of
graphics/py-qt-hpp-gui.

objdump -p /opt/openrobots/lib/gepetto-gui-plugins/hppmanipulationwidgetsplugin.so
| grep omni
NEEDED               libomniDynamic4.so.2
NEEDED               libomniORB4.so.2
NEEDED               libomnithread.so.4

while all of its dependencies are correct.

I noticed this in cmake/idlrtc.cmake:

macro(GENERATE_IDLRTC_FILE FILENAME DIRECTORY)
find_program(OMNIIDL omniidl)

Does it by chance pick up the wrong omniidl? (not sure if that would
have the above effect though).

Or maybe this comes from this part of cmake/Config.cmake.in:

FOREACH(pkgcfg_dep ${@PROJECT_NAME@_PKG_CONFIG_DEPENDENCIES})
[...]
ADD_REQUIRED_DEPENDENCY(${pkgcfg_dep})
[...]
ENDFOREACH()
ENDIF(COMMAND ADD_REQUIRED_DEPENDENCY)

that picks up an omniORB4 pkg-config dependency from
gepetto-viewer-corba and hpp-manipulation-corba:

gepetto-viewer-corbaConfig.cmake:set("gepetto-viewer-corba_PKG_CONFIG_DEPENDENCIES" "omniORB4 >= 4.1.4;openscenegraph >= 3.2;openthreads >= 2.6;openscenegraph-osgQt5;qgv")
hpp-manipulation-corbaConfig.cmake:set("hpp-manipulation-corba_PKG_CONFIG_DEPENDENCIES" "omniORB4;omniORB4 >= 4.1.4;omniDynamic4 >= 4.1.4")

Then I don't know how this is used but maybe this forces cmake to link
with whatever omniORB4 it finds with pkg-config and it happens to pick
up the wrong?

If this rings you any bell ...

Yes, maybe with multiple omniidl programs available, the outcome would depend on some environment variable ordering.

But maybe we could workaround this simply by removing omniorb packages from the affected build VM ?

On Thursday 7 Nov 2024, at 14:24, Guilhem Saurel wrote:

But maybe we could workaround this simply by removing omniorb
packages from the affected build VM ?

This seems indeed possible, as by chance omniorb does not seem to be
currently required by any other package in the base system.

However, this will not fix the issue for people building from source,
so it would probably be more robust to at least identify what the
issue is really?

I pushed a patch to *-corba packages required by py-qt-hpp-gui.
I hope this will fix the linking issue of hppwidgetsplugin.so.

At least, the linker command now contains the full path to omniORB
libraries, instead of a mere -lomniORB etc. (For some reason, the -L
linker flag found in the INTERFACE_LINK_LIBRARIES property of exported
targets is not added to the command line). Using -L is not robust to
the flags ordering anyway, so the full path should improve the
situation and this is more in line with cmake recommandations.

Let's see how this looks like after the bulk builds.

That looks ok now, at least for py-qt-hpp-gui.

As a side effect, hpp-template-corba-5.2.0r1 is broken on ubuntu-1804,
due to cmake<3.12 not populating the pkg-config
<prefix>_LINK_LIBRARIES variable. However, hpp-corbaserver was already
not supported (matio<1.5.17), so this does not change much the situation.

Do you think hpp-template-corba-5.2.0r1 can be disabled on ubuntu-1804
by requiring cmake>=3.12 or should the <prefix>_LINK_LIBRARIES
backported there (it's a simple cmake macro to add) ?