The script relocate_sdk.py contains a bug(s) that can cause to install an SDK with incorrectly relocated/corrupted files.
If installing the SDK into a non-default location and if the path to the new SDK location is longer than the path of the default SDK location, we will overwrite some data inadvertently. The intent is to write 4096 bytes, but we will in fact end up writing more than that, easily proved by a printout:

...
while (offset + 4096) <= sh_size:
                    path = f.read(4096)
                    new_path = old_prefix.sub(new_prefix, path)             
                    # pad with zeros
                    new_path += b("\0") * (4096 - len(new_path))
                    #print "Changing %s to %s at %s" % (str(path), str(new_path), str(offset))
                    # write it back
                    f.seek(sh_offset + offset)
                    print("Write length: %i" % (len(new_path)))
                    f.write(new_path)
....

This will overwrite/corrupt the beginning of the next entry we want to process.
The reason we do not always observe the problem is (IMHO) because there is another bug, related to file flushing, basically compensating the overwriting bug. 
I believe adding an explicit flush to the code proves my point:
                    # write it back
                    f.seek(sh_offset + offset)
                    print("Write length: %i" % (len(new_path)))
                    f.write(new_path)
                    f.flush()

The flush should make no difference, yet it will guarantee an entry to be overwritten (if the conditions are "right": i.e. new_path longer than 4096). 

Similar code is used in two places.

At first I observed this with a python3 system, but it turns out it has nothing to do with python3, it was also observed with python2 and installing SDK on a NFS mounted drive (most likely due to some differences in fflush)
The remedy would be to ensure we always write 4096 bytes without the assumption that len(new_path) is 4096 bytes.