/usr/lib/meta hierarchy needs symlink mirroring

[stephenrkell]

Some systems have /lib as a symlink to /usr/lib. Although I believe this is foolish, it surfaces a problem in how we name files in /usr/lib/meta. Ideally the aliasing structure there would mirror the aliasing structure under /.

For a while I avoided this by aggressively realpathing the pathnames of libraries. So, only the realpath alias would need to be present under /usr/lib/meta. But there was a particular way in which that turned out not to be correct: stephenrkell/liballocstool@d5cf45d. The issue is that a .gnu_debuglink section might give a relative path that must be interpreted relative to this non-'real' directory. This only affects tools that need to follow these debug links.

In liballocs proper, we pass the file name as found in the link map, through librunt's dynobj_name_from_dlpi_name. This does indeed perform realpath on it. So we still look for meta-DSOs by the DSO's realpath. That is why we look in /usr in this problematic case, even for an object that the ld.so has found under /lib.

Maybe a quick fix is not to pass it through realpath? That function in librunt does two things: replace "" with the real executable name, and pass the link map's name through realpath_quick.

A further complexity is that get_exe_fullname() sometimes does realpath and sometimes just does a single readlink of /proc/self/exe. Is that guaranteed to point to a canonical ("resolved") path? It is not clear from the proc(5) manual page, although that strongly suggests it will be an absolute path at least.

So the proper fix is to refactor all this to be consistent about whether realpath is applied or whether a merely absolute path is delivered, and then add code to tools/Makefile.meta that will reproduce symlinks rather than just do mkdir -p. The quick fix is just to avoid realpath'ing library names.

[stephenrkell]

I recently refactored get_exe_fullname() into command and basename variants in librunt (stephenrkell/librunt@a16baf7). I think these don't need to do realpath in any case... next: try this.

[stephenrkell]

There's a first attempt at the symlink-mirroring thing in 1e8b6ad. It seems to be slightly broken just now.