TL;DR: unless you're writing your own dynamic linker, i'm not sure why you'd write an ldd?
personally i don't think a readelf-based ldd makes much sense? there are a ton of weird special cases that mean you really do need the "suck it and see" implementation --- bionic already just has a one-line shell script that passes an argument to the dynamic linker (and i think glibc and musl work this way too). which isn't to say that the question doesn't sometimes come up of "i'd like to print the transitive closure of DT_NEEDEDs *on the host*" but note that that's *not* the same thing, and so even if someone does write that, it probably deserves a different tool name and a big "note that your run-time mileage may vary wildly". On Thu, Jan 13, 2022 at 11:14 AM Rob Landley <r...@landley.net> wrote: > > In theory ldd is a subset of readelf, so we've already got most of the code. > In > practice, the OTHER thing it does is try to dlopen() each library so it can > get > a path and address out of /proc/self/maps. > > The problem is if you're statically linked, bionic links in a dlopen() stub > return ing NULL. Which makes sense because you couldn't USE the dlopen() > result > because of the old "now we have two heap pointers and if you malloc() from the > dynamic one and free() into the static one and you've cross-linked your heaps" > problem, but all I'm trying to do is get the path to the file and the > preferred > load address. > > Not entirely sure the right thing to do here. This is one of those "almost > entirely trivial, except for the land mine" things. I guess I can just print > the > library name from the ELF info but not the => part when dlopen() returns null? > > Rob > _______________________________________________ > Toybox mailing list > Toybox@lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net