3 ms·
The tool is interesting, but doesn't account for the fact that some shared libraries opened via dlopen are done so lazily. So it might miss those if you haven't
by surajrmal 3y ago
The tool is interesting, but doesn't account for the fact that some shared libraries opened via dlopen are done so lazily. So it might miss those if you haven't executed a code path that triggers them to load.
The other side of not accidentally loading more into your process than you thought is breaking down shared libraries into increasingly smaller sizes. In its limit I imagine it would be akin to a function per shared library, which probably defeats the point a bit.
- rwmj 3y agoFrom the article it seems like that might be the point, to visualise what the binary actually uses, eg. if you use different preferences.
- Retr0id 3y agoIf the code path that loads the library is never hit, does it really count as a dependency?
- sooperserieous 3y agoIt does if someone is intentionally sending it down that code path for exactly that reason.
- marcosdumay 3y agoIf your tests don't exercise a bug, is it still there?
- eqvinox 3y agoLazy binding for dlopen is disabled when the LD_BIND_NOW environment variable is set to a nonempty value, cf. https://man7.org/linux/man-pages/man3/dlopen.3.html https://man7.org/linux/man-pages/man3/dlopen.3.html
- tedunangst 3y agoThat doesn't mean the program is going execute all the dlopen() calls at start up.
- eqvinox 3y agoThat is true, but the root comment was specifically referring to dependencies of dlopen'ed libs not getting loaded. That one is 'fixable'. (Btw, I'm pretty sure dlopen itself can't be lazy, due to needing to run constructors; the root comment is a bit vaguely worded... but ofc that only matters after dlopen is called.)