On Mon, Oct 10, 2011 at 10:49:01AM +0200, Carmelo AMOROSO wrote: > We now fortunately have the opportunity to run uClibc ld.so in > stand-alone mode as well, so this revised implementation should be safe.
Personally I do not see a big win in letting ldd apply a non-standard search path. This can be convenient but (IMHO) seldom important and (again IMHO) never crucial. The actual location of the libraries is easy to find out, given their names and the [LD_LIBRARY_] path, without adding code and extra security issues to think about to ldd. Different people may have different preferences about the balance of convenience and complexity, so the extra code and effort might be worth the gain. Anyway, no gain for my actual use of ldd. On the more philosophical level, I see ldd as a tool to explore a binary, period. LD_LIBRARY_PATH does not belong to the binary and the extra information "where the libraries would be found given a certain search path" is useful but is not the binary's property. In my eyes the functionality would be more consequently implemented as a script taking a list of libraries' names from ldd + a search path and resolve the libraries to files. If you think that such "purity" contradicts practical uses, it is quite the opposite - I have to routinely parse glibc ldd output to get the actual libraries' names instead of the "resolved" file names which is _not_ what I need. So, actually, I'd prefer "no resolution at all". (Of course ldd should tell if the binary insists on looking in certain places via RPATH - which I do not like but want to know.) Regards, Rune _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
