On 10/10/2011 11.49, [email protected] wrote: > 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. >
Hi Rune, > Personally I do not see a big win in letting ldd apply a non-standard > search path. > I could agree with you, but one of the big concerns I often see (even in the embedded world) with customers when trying to pushing them to migrate fro a glibc based system to uClibc is about "compatibility" in the most extended meaning. This is just one example. I'm strongly convinced that this is key in supporting the adoption of uClibc vs glibc. > This can be convenient but (IMHO) seldom important and (again IMHO) > never crucial. > never said it's 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. > you said... different people and different preferences > 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. > I agree on this concept, but I can't see your concerns in supporting this extension (once the security hole is fixed by using the stand-alone mode) > 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. > out of scope I think > 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.) > if you think it's worth... patches are welcome > Regards, > Rune > > Cheers, Carmelo _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
