Embed .so next to binaries and properly set their RPATH

[NathanReb]

This now copies shared libraries next to the binary itself and sets the binary RUNPATH to $ORIGIN.

I tested this locally with LD_DEBUG=libs and it seems to work just fine as they do get picked:

$ LD_DEBUG=libs alt-ergo
    806019:	find library=libz.so.1 [0]; searching
    806019:	 search path=/opt/alt-ergo/bin/glibc-hwcaps/x86-64-v3:/opt/alt-ergo/bin/glibc-hwcaps/x86-64-v2:/opt/alt-ergo/bin/tls/haswell/x86_64:/opt/alt-ergo/bin/tls/haswell:/opt/alt-ergo/bin/tls/x86_64:/opt/alt-ergo/bin/tls:/opt/alt-ergo/bin/haswell/x86_64:/opt/alt-ergo/bin/haswell:/opt/alt-ergo/bin/x86_64:/opt/alt-ergo/bin		(RUNPATH from file alt-ergo)
    806019:	  trying file=/opt/alt-ergo/bin/glibc-hwcaps/x86-64-v3/libz.so.1
    806019:	  trying file=/opt/alt-ergo/bin/glibc-hwcaps/x86-64-v2/libz.so.1
    806019:	  trying file=/opt/alt-ergo/bin/tls/haswell/x86_64/libz.so.1
    806019:	  trying file=/opt/alt-ergo/bin/tls/haswell/libz.so.1
    806019:	  trying file=/opt/alt-ergo/bin/tls/x86_64/libz.so.1
    806019:	  trying file=/opt/alt-ergo/bin/tls/libz.so.1
    806019:	  trying file=/opt/alt-ergo/bin/haswell/x86_64/libz.so.1
    806019:	  trying file=/opt/alt-ergo/bin/haswell/libz.so.1
    806019:	  trying file=/opt/alt-ergo/bin/x86_64/libz.so.1
    806019:	  trying file=/opt/alt-ergo/bin/libz.so.1
    806019:	
    806019:	find library=libgmp.so.10 [0]; searching
    806019:	 search path=/opt/alt-ergo/bin		(RUNPATH from file alt-ergo)
    806019:	  trying file=/opt/alt-ergo/bin/libgmp.so.10
    806019:	
    806019:	find library=libm.so.6 [0]; searching
    806019:	 search path=/opt/alt-ergo/bin		(RUNPATH from file alt-ergo)
    806019:	  trying file=/opt/alt-ergo/bin/libm.so.6
    806019:	 search cache=/etc/ld.so.cache
    806019:	  trying file=/lib/x86_64-linux-gnu/libm.so.6

A quick side note on RUNPATH vs RPATH for future reference:

RPATH is checked before LD_LIBRARY_PATH while RUNPATH is checked after, allowing it to be overridden. If both are set, RPATH is ignored in favor of RUNPATH. RPATH appears to be deprecated and discouraged, in favor of RUNPATH specifically because the latter has lower priority than LD_LIBRARY_PATH. Following those recommendation I settled for RUNPATH. If we ever want to change that, we need to pass --force-rpath to patchelf.

It's also worth noting that some applications that I have installed on my machine, namely Zulip and Obsidian, use RPATH.

[NathanReb]

@ddeclerck Does the windows error look familiar?

[ddeclerck]

@ddeclerck Does the windows error look familiar?

Not really, though it indicates the produced MSI file can not be found. Maybe it has to do with it's name - remember I had to fix a dot/hyphen issue in the name.

You could add a dir *.msi instruction in the step Test: create package so that we know if an MSI file has actually been produced and what its name could be.

[NathanReb]

I think the installation went fine, it can't find the installed executable though:

Run & "C:\Program Files (x86)\ocp-indent\ocp-indent.exe" --version
&: D:\a\_temp\5886c84a-aa0c-4d06-9e3e-1b95b826704d.ps1:2
Line |
   2 |  & "C:\Program Files (x86)\ocp-indent\ocp-indent.exe" --version
     |    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | The term 'C:\Program Files (x86)\ocp-indent\ocp-indent.exe' is not recognized as a name of a cmdlet, function,
     | script file, or executable program. Check the spelling of the name, or if a path was included, verify that the
     | path is correct and try again.
Error: Process completed with exit code 1.

[NathanReb]

That being said, I don't think the failure is related to this PR so a review is still welcome!

[ddeclerck]

I think the installation went fine

No it did not, the MSI could not be found (see the step above, that fails but this failure is not detected by GA) :

> Run msiexec /i ocp-indent-1.8.1.msi /qn /L*v wixlog.txt ALLUSERS=2 MSIINSTALLPERUSER= 
This installation package could not be opened.  Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.

[ddeclerck]

That being said, I don't think the failure is related to this PR so a review is still welcome!

PR itself is good to go.