--set-rpath corrupts symbols that are suffix of current RPath

[dsludwig]

The GNU linker merges together items that share a common suffix in the dynamic string table, where RPath lives. If you have an Rpath like somedir/lib and a symbol called b, the symbol b will point to the end of the Rpath. When the Rpath is replaced, the symbol's name will be changed to X.

See http://dsludwig.github.io/2019/02/12/building-up-to-something.html for references

[LongHairedHacker]

Good catch, just ran into the very same problem in an OpenWRT build.

They use patchelf to set an empty rpath, the affected binary uses system from glibc and unfortunately my rpath ended in system. To add to the confusion the rpath was reordered due to some seemingly unrelated changes in the build process, so all of the sudden I was unable to link system and got XXXXXX instead. Six times X unfortunately is a really common string in the codebase as it is the template string for mktemp. Also one does not simply google XXXXXX.

Any pointers on how to work around this bug? Changing the our order of rpath is not really an option, it changed 'on its own' when we initially found this bug and I don't know how to keep it in a fixed order.

[DerDakon]

If you comment out the following 4 lines in modifyRPath() it should work:

    if (newRPath.size() <= rpathSize) {
        strcpy(rpath, newRPath.c_str());
        return;
    }

Also the memset() ~6 lines before has to go away. That will probably break things elsewhere, e.g. on Nix, so this is likely just an intermediate solution.

[ghost]

I think @eliasnaur's assessment here is accurate.