revdep_rebuild: Fix issue where library is a full path

[mackal]

app-editors/neovim-0.10.0 has one of it's libraries referenced by a full path, which seems to be causing it want to rebuild.

On my system scanelf shows: /usr/bin/nvim;nvim;;libluv.so.1,libvterm.so.0,/usr/lib64/lua/5.1/lpeg.so,libmsgpack-c.so.2,libtree-sitter.so.0,libunibilium.so.4,libluajit-5.1.so.2,libm.so.6,libuv.so.1,libc.so.6;ELFCLASS64

In the LibCheck.search() function it was passing "/usr/lib64/lua/5.1/lpeg.so" to LibCheck.check() which searches by basename, which of course isn't going to match.

[mattst88]

I've filed https://bugs.gentoo.org/932671 about neovim linking against lpeg.so, since that seems wrong.

It's not clear to me what revdep-rebuild should do in this case.

[mackal]

I'm not entirely sure what they are doing is kosher or not, but there are references to lpeg stuff in their C files. And I do find it's a tad suspicious this is the only case where this is an issue, but I assume it's working fine, not 100% sure how to test in neovim.

I did have another idea for testing if it's trying to load a library by full path, but this seemed most straight forward and lowest overhead (although, probably not portable to ahh Windows)

[correabuscar]

Thanks! Works for me, no more revdep-rebuild(s) on every run!

[thesamesam]

OK, thinking about it more, it makes no sense to rebuild indeed for this case, even if neovim is wrong.