Portability: add a configure option to enforce RPATH/RUNPATH from learned library locations

[jimklimov]

As was found in #2781, some distros that put additional packages into "uncommon" locations (e.g. not into /usr/lib searched by default), we can build and link NUT binaries following the -L/some/path instructions learned from command-line ./configure --with-something-libs options or from pkg-config.

However to run such binaries, the run-time LD linker needs either its built-in defaults, system configuration (crle on Solaris/illumos, etc.) or the LD_LIBRARY_PATH (frowned upon) to point to additional locations, or for the binaries (programs and shared libs) to say what they prefer - via RPATH and RUNPATH attributes of those binaries (see objdump, elfdump -d, dump -Lv etc. for the platform).

• Note: this inability to run also impacts our discovery of usable dependencies in the configure script, e.g. where we AX_RUN_OR_LINK_IFELSE() for libgd located under /opt/ooce/lib in OmniOS -- the build/link part finds it well, but the run-time test fails, and we refuse to build CGI there.

Normally the same data that we found the libraries for linking with (-L options) should convey the -R values if needed for run-time. In practice, many *.pc files delivered by various projects do not bother to do so, and then when packaged into uncommon locations, the packaging recipes did not think of adding those instructions either.

This issue tracks an idea to add an option to NUT configure script to rewrite the located -L options into additional -R (and/or -Wl,-rpath,... etc.) options for the linker, at least for "uncommon locations", and so to optionally compensate for poor quality of information provided by dependencies. Since #2674 we have a precedent in m4/nut_check_libnss.m4 and LIBSSL_LDFLAGS_RPATH to build upon.

Note the NUT binaries do get the RPATH to NUT installation location built in, and typically expect the major-versioned symlink like libupsclient.so.6 or libnutscanner.so.2 to be present there. Investigating how autotools achieve that, and emulating it for third-party dependencies, may be another path to solution.

See also #1498 as this may impact usability of "simple" NUT builds on OmniOS in particular.

UPDATE: While troubleshooting for investigations, ldd (otool on MacOS) can be used to see which libraries a prog/lib wants, and use further tools to search where it would try to find them:

You can try something like elfdump -d, readelf -d, dump -Lv etc. depending on the platform and installed toolkits, to see in which custom locations the system dynamic linker would automatically search for shared objects (there are also locations built into the linker itself and/or its system-wide configurations, so the likes of common /usr/lib are not listed here). For example:

:; readelf -d `which upsc` | grep -E 'R.*PATH'
 0x000000000000001d (RUNPATH)            Library runpath: [/usr/local/ups/lib]

...or for the freshly-built program, use its likely path(s) in the build workspace:

:; elfdump -d ./clients/{,.libs/}upsc | grep -E 'R.*PATH'
       [8]  RUNPATH           0xb2e               /usr/local/ups/lib:/usr/gcc/11/lib/amd64
       [9]  RPATH             0xb2e               /usr/local/ups/lib:/usr/gcc/11/lib/amd64

For completeness,

:; dump -Lv ~/nut/clients/.libs/upsc | grep -E 'R.*PATH'
[9]     RUNPATH         /usr/local/ups/lib:/usr/gcc/11/lib/amd64
[10]    RPATH           /usr/local/ups/lib:/usr/gcc/11/lib/amd64

[jimklimov]

A hot-fix for OmniOS specifically took the form of blanketly adjusting default LDFLAGS when /opt/ooce/lib is seen. This allows USB, CGI and similar artifacts to get built and to run, even if it is an overkill to have these RPATHs in each binary.

Proper and generic fix should get investigated later.