Russ Allbery wrote: > Raphael Geissert writes: > >> It was basically that; requiring [^_] because some libs incorrectly >> export symbols that should not be exported (i.e. private). The >> assumption is that if no public symbol is exported then it is a >> plugin. > > Don't plugins have to export symbols, though? All PAM modules do, for > instance. Usually, plugins export symbols the same way as shared > libraries and the loading application calls into specific symbols (or > uses a struct for calling points).
Indeed, I didn't think about that. > >> On my machine it matches /usr/lib/libkaffeine*.so, which should be in >> some place like /usr/lib/kaffeine/ > > I think you're getting false positives from the fact that all C++ > symbols start with _Z due to mangling. I get hits for that search for > basically everything written in pure C++, including libraries that I > know are supposed to be public. Sure, that's ok. I forgot about mangled symbols, nm should be called with -DC, not just -D. > > If I run: > > for f in /usr/lib/*.so.* ; do > nm -D "$f" | egrep -q '^[a-f0-9]+ [^U] ([^_]|_Z)' || echo "$f is > private" > done > > instead, I get three libraries on my system: > > libGLcore.so.1 > libgmp.so.3 > libnvidia-tls.so.1 > > libgmp appears to be an artifact of how GMP handles its naming > conventions, GLcore seems to be a weird special case, and > libnvidia-tls.so is just some bizarre proprietary thing but isn't a > plugin. > So far I've came up with: for f in /usr/lib/*so.*; do nm -DC "$f" | grep -q " virtual thunk" && echo "$f is private" done Which seems to give good results. It is based on the assumption that plugins use/implement virtual functions, although it only works with C++ libs. What do you think? good enough to add it as an experimental/wishlist/possible tag? Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
