More in-place updates by exploiting colons in rpath

[haampie]

It'd be nice if patchelf could interpret colons ::::::::::::::::::::: in an rpath as padding / scratch space to write in.

On macOS the linker has a -headerpad_max_install_names flag which reserves a fixed amount of space for the install_name.

On Linux there's no such flag for sonames, but a common trick (e.g. in CMake) is to reserve space in rpaths by padding with colons -rpath :::::::::::: since colons are separators between paths. This string of colons can be used by patchelf, but currently it doesn't do that.

For example, in this case patchelf copies the string table:

$ gcc -shared -o libf.so -Wl,-soname,libf.so,-rpath,$(printf ':%.0s' {1..1024}) # reserve 1024 bytes of scratch space
$ wc -c libf.so 
15432 libf.so
$ patchelf --set-soname libf.so.1 libf.so 
$ wc -c libf.so 
17736 libf.so

But looking at the hexdump, it could have changed the soname in-place:

$ hexdump -C libf.so 
...
000003a0  6c 69 7a 65 00 6c 69 62  66 2e 73 6f 00 3a 3a 3a  |lize.libf.so.:::|
000003b0  3a 3a 3a 3a 3a 3a 3a 3a  3a 3a 3a 3a 3a 3a 3a 3a  |::::::::::::::::|
*
000007a0  3a 3a 3a 3a 3a 3a 3a 3a  3a 3a 3a 3a 3a 00 00 00  |:::::::::::::...|

(My goal is to replicate ld -headerpad_max_install_names + install_name_tool -id ... more closely, without the risk of breaking binaries in subtle ways because of the machinery involved to create a new string table)