built prt4cmd is not runnable on linux about cityengine-sdk HOT 5 CLOSED

Apologies for your troubles - which SDK version do you use?

from cityengine-sdk.

This bug was initially encountered when using 3.1.9666/esri_ce_sdk-3.1.9666-rhel7-gcc93-x86_64-rel-opt which is the current default in cmake script for prt4cmd
When I changed the cmake to download 3.2.9903/esri_ce_sdk-3.2.9903-rhel8-gcc112-x86_64-rel-opt, the same bug is observed

from cityengine-sdk.

Thanks, I can reproduce the issue with the default WSL Ubuntu distro. Will investigate some more and let you know here.

from cityengine-sdk.

The problem is caused by a difference in runtime linker behavior between Ubuntu and (our officially supported) RHEL-based distros (RHEL, Alma, Rocky, ...).

I'm probably oversimplifying, but Ubuntu by default interprets the RPATH value as RUNPATH. One difference between the two is that RUNPATH is only used for the current binary (prt4cmd in this case) while RPATH is inherited by all the dependencies. This means that the $ORIGIN value in prt4cmd is inherited also by libcom.esri.prt.core.so on RHEL-based systems and therefore libgluetess.so is found.

An alternative fix when compiling prt4cmd in WSL2 Ubuntu is to add this line to CMakeLists.txt:

target_link_options(${PROJECT_NAME} PRIVATE -Wl,--disable-new-dtags)

This will force the use of RPATH (RUNPATH is considered a "new" tag).

You can see the difference when looking at the RPATH/RUNPATH entries in the output of readelf -d install/bin/prt4cmd: on a RHEL-based distro it says (RPATH) Library rpath: [$ORIGIN] and on (WSL2) Ubuntu it says (RUNPATH) Library rpath: [$ORIGIN].

from cityengine-sdk.

I've put corresponding actions in our backlog to fix the issue in one of the next releases.

Taking the liberty to close the issue. Feel free to reopen or create a new one in case of additional issues or questions.

from cityengine-sdk.