On 11/28/21 16:17, Florian Weimer wrote: > * Jacob Kroon: > >>> The RUNPATH strings are in the string table, so it's necessary to >>> allocate space there, and be able to find it during patching. >>> >>> Solaris offers this mechanism: >>> >>> | DT_SUNW_STRPAD >>> | >>> | The total size, in bytes, of the unused reserved space at the end of >>> | the dynamic string table. If DT_SUNW_STRPAD is not present in an >>> | object, no reserved space is available. >>> >>> Would that help in your case as well? >>> >> >> The problem is that for two different build I pass two different >> -Wl,--rpath=<path>, and they are of different length. So I'd like to >> reserve a maximum size, at link-time, which becomes the same in both >> builds, so that when I later remove the rpath's, the binaries become >> identical. > > In the file, there is no array of some number of characters that > contains the null-terminated RUNPATH string, an array to which just more > null bytes could be added at the end. DT_RUNPATH contains an offset > into the string table. The null-terminated string could be used for > something else. For example, if the RUNPATH is > "/usr/lib64/sys/library.so.3", and the link edit needs the string > "library.so.3" for something else, it can point into the RUNPATH string > to get that. So it's not valid in general to patch the string in-place, > let alone change its length. > > That's why I think something like the Solaris approach is needed: The > new RUNPATH value would come from the reservation, the offset in > DT_RUNPATH points to it, and the original string table is not modified > at all. > Aha, thank you for explaining. I suppose gnu ld doesn't try to optimize for usage of substrings in RUNPATH, thus making if fairly easy to change it post linking. But can I then specify during link time that RUNTIME should go in a "reserved" area, whose size I can also control ? I hope I understood you correctly. Jacob
