On 18-Dec-05, at 9:43 PM, Dan Kegel wrote:
Mike Hearn (who wrote relaytool) said that Debian objected to it (see http://plan99.net/autopackage/Linux_Problems#weak ) because it would defeat Debian's automatic dependency scanning. Presumably implementing DT_USEFUL directly would make them happy.
Yeah, I agree with Mike that making automated dependency scanners a barrier for such things is sort of like cutting off your nose to make your glasses fit better, only you don't gain the benefit of additional nasal portability.
If the automated dep scanner isn't good enough, you fix it or you go back to doing it manually. It's hard enough to get stuff working without people taking useful tools like relaytool out of our hands.
Does anyone have a better link for the definition of DT_USEFUL, by the way, or is this something Mike Hearn came up with himself?
Mike might well have come up with the DT_USEFUL term, but at least IRIX has had this support for ages. The key google inputs are "#pragma optional" and "_MIPS_SYMBOL_PRESENT". If you have access to an IRIX system, /usr/include/optional_sym.h is another good source of information.
The basic model is that an optional symbol is resolved against a magic, well-known symbol if it can't be found in a real library. I think IRIX used "_missing_function", but it might be nice for it to work for non-function symbols as well and reflect it in the naming. A macro compares a given symbol's address to _missing_function, and, if they don't match, can go ahead and use the symbol normally.
I must preface any such remark with admission of my complete and joyous ignorance of bfd and Linux linker internals, but: it doesn't sound like the science of rockets to add such support to our toolchain and ld.so.
Mike
_______________________________________________ Desktop_architects mailing list [email protected] https://lists.osdl.org/mailman/listinfo/desktop_architects
