Make Rule Misbehavior with deploy mode `INSTALL` on Linux when using SONAME for the dependency

[jeonghanlee]

Describe the bug

open62541 generates its shared library using standard shared library versioning and naming conventions. When using the INSTALL option, the current build rule copies only libopen62541.so into the installation lib folder after compilation. Unfortunately, libopcua.so was linked with a specific SONAME (defined as libopen62541.so.1), and as a result, libopcua.so cannot find or understand libopen62541.so when both are in the same directory.

To Reproduce
Steps to reproduce the behavior:

1. Follow the standard building procedure for the project.
2. Configure CONFIG_SITE.local with the following settings:

configure/CONFIG_SITE.local
     1	INSTALL_LOCATION:=/home/jeonglee/epics/1.1.2/debian-12/7.0.7/modules/opcua-0.11.0
     2	USR_CXXFLAGS_Linux += -std=c++11
     3	OPEN62541 = /home/jeonglee/open62541
     4	OPEN62541_DEPLOY_MODE = INSTALL
     5	OPEN62541_LIB_DIR = $(OPEN62541)/lib
     6	OPEN62541_SHRLIB_DIR = $(OPEN62541_LIB_DIR)
     7	OPEN62541_USE_CRYPTO = YES

3. Observe the installed library structure and the dynamic linking:

$ tree /home/jeonglee/epics/1.1.2/debian-12/7.0.7/modules/opcua-0.11.0/lib/linux-x86_64/
├── libopcua.a
├── libopcua.so -> libopcua.so.0.11
├── libopcua.so.0.11
└── libopen62541.so

Even though libopen62541.so is present in the same directory, ldd libopcua.so shows it still references the library from the original OPEN62541 build/installation path:

$ ldd libopcua.so
libopen62541.so.1 => /home/jeonglee/open62541/lib/libopen62541.so.1 (0x00007f892451b000)

4. If the OPEN62541 folder is removed, libopcua.so fails to locate its dependency (libopen62541.so.1), as it relies on the SONAME embedded in libopen62541.so:

$ ldd libopcua.so
libopen62541.so.1 => not found

Expected behavior
The build process should copy and install the exact shared library files (including their symbolic links for versioning) into the specified installation folder, ensuring that dynamically linked applications can find them without relying on the original build directory.

Setup (please complete the following information if applicable):

• OPCUA Support: master branch
• Platform: Debian 12
• EPICS Base: 7.0.7
• Client library: 1.3.15

Additional context

The key rules are

1. opcua/devOpcuaSup/open62541/Makefile.rules

   Line 48 in d206f88

   EXTLIB_INSTALLS += $(addprefix $(INSTALL_SHRLIB)/, \

2. opcua/devOpcuaSup/open62541/Makefile.rules

   Line 54 in d206f88

   $(INSTALL_SHRLIB)/$(SHRLIB_PREFIX)%$(SHRLIB_SUFFIX_BASE) : $(OPEN62541_SHRLIB_DIR)/$(SHRLIB_PREFIX)%$(SHRLIB_SUFFIX_BASE)

As a workaround, I am currently removing the SONAME from libopen62541.so before building libopcua.so.

After applying this modification, ldd libopcua.so now correctly resolves the dependency:

libopen62541.so => /home/jeonglee/epics/1.1.2/debian-12/7.0.7/modules/opcua-0.11.0/lib/linux-x86_64/././libopen62541.so (0x00007faa7e73b000)

This indicates that libopcua.so can now successfully locate libopen62541.so within its installation directory.

[ralphlange]

Ack.
Correct. The INSTALL mode fails to copy over the correct library files when SONAME is used.

Has not been tested well enough ... INSTALL mode is primarily targeted at Windows, where copying dependency libraries into the application is a very common way of operation and SONAME does not exist.
On Linux, SYSTEM or PROVIDED modes are more common. EMBEDDED works equally well for both.