* 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. Thanks, Florian
