make shared libraries load from runtime ACT_HOME by relative search path

[olerichter]

What does this pull request improve:

• the compiled in search path for shared object libs (RUNPATH/ rpath) is no longer hard coded to the ACT_HOME path at compile time, but is now taking runtime location of the binary and searches relative to it, the old search path is kept for backup.
• the configure script will accept external CFLAGS passed to it to enable custom include/link locations for example if libedit or zlib are installed in a custom path.
• adds runpath to compile flags for prsim (because of libedit)

Why do that change:

This changes where triggered by me having to build the act tool chain for a shared network install. In my case this install is mounted to both centos 7 servers and ubuntu 20.04LTS local machines. To avoid having different binaries and having to install dependencies on all local machines I decided to put the required external so libs also in ACT_HOME/lib.

The build scripts I put at https://github.com/bics-rug/act-toolchain-build , I could build+publish nightlys from the oss parts (if you think that's helpfull for others) that should run on most gnu/linux distributions >2013 out of the box, without installing dependencies (the CI is testing that). The CI is already building a subset of the tools for the start, more will come. I am not packaging them at the moment but that would be easy.

changes to the binaries look like:

binaries:

readelf -d act/bin/interact | head -14

Dynamic section at offset 0x1ed60 contains 35 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libactpass_sh.so]
 0x0000000000000001 (NEEDED)             Shared library: [libact_sh.so]
 0x0000000000000001 (NEEDED)             Shared library: [libvlsilib_sh.so]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libedit.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/home/user/git/act-toolchain-build/act/lib]
 0x000000000000000c (INIT)               0x6000

libraries:

readelf -d act/lib/libactchp2prspass.so | head -11

Dynamic section at offset 0xdd68 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libact_sh.so]
 0x0000000000000001 (NEEDED)             Shared library: [libvlsilib_sh.so]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/home/user/git/act-toolchain-build-oss/act/lib]
 0x000000000000000c (INIT)               0x4000

before it was :

 0x000000000000001d (RUNPATH)            Library runpath: [/home/user/git/act-toolchain-build-oss/act/lib]
 
for $ACT_HOME = /home/user/git/act-toolchain-build-oss/act  set at compile time

[olerichter]

I realized that there is a bug that i have to track down as the shared libraries are not loaded with the specified runtime path

[olerichter]

@rmanohar let me know what you think and if you would consider that change. It works now as intended, sadly custom runtime vars in RUNPATH are not allowed, updated the description. Also my build IC now tests the build version on centos 7, ubuntu 18 + 20, and debian stable + oldstable. I kept the compile time version of ACT_HOME in there as backup so that make runtest still work as it uses the not installed binaries by default.

[rmanohar]

This looks reasonable. Is $ORIGIN a Linux-only feature? If so, we could put that in a test within the script for linux as the $baseos.

[olerichter]

I will do some more research what I could find out so far that $Origin is supported on all gnu ld runtime linkers, but its not part of the POSIX spec.
mac os you are anyway excluding already, i will make a commit that checks the baseos linux/solaris on the weekend!

i found references for linux:

$ORIGIN and rpath

ld.so understands the string $ORIGIN (or equivalently ${ORIGIN}) in an rpath specification (DT_RPATH or DT_RUNPATH) to mean the directory containing the application executable. Thus, an application located in somedir/app could be compiled with gcc -Wl,-rpath,'$ORIGIN/../lib' so that it finds an associated shared library in somedir/lib no matter where somedir is located in the directory hierarchy. This facilitates the creation of "turn-key" applications that do not need to be installed into special directories, but can instead be unpacked into any directory and still find their own shared libraries. 
https://linux.die.net/man/8/ld-linux

solaris:
https://docs.oracle.com/cd/E19455-01/806-0477/dev-env-8/index.html

for BSD there is support but i need to test if its automatic and works because the man pages talk about an option
openBSD,
https://man.openbsd.org/ld
freeBSD
https://www.unix.com/man-page/freebsd/1/ld.so/

[olerichter]

has a check for linux and solaris added

[rmanohar]

Looks good. I will merge this shortly.