On Wed, Jun 29, 2011 at 10:16 AM, I wrote: > Our linker (these days) does "direct binding" so in theory, this > library (libreadline) can link with -lcurses and applications can > link with ncurses or whatever and all should be well.
After writing the above, it occurred to me that many people might not understand how "direct binding" works. With "direct binding", libraries only resolve external symbols from libraries listed as direct dependents. This implies that when I build a library, I normally should link it with all libraries it needs to resolve any externals it calls. Normally, one should link with the "-z defs" option to ld, which lets you know if you've accidentally omitted any necessary dependent libraries. (Unfortunately, most 3rd party s/w does not use -z defs) Further, "direct binding" means that libraries do NOT export symbols from their dependent libraries. So in the case of libreadline, it can link tgetent etc from libcurses and NOT cause any of those symbols to be exposed to any programs or libraries linked with libreadline. One can verify this by trying to call libcurses functions from a program that links with just libreadline. The curses functions will be unresolved. There are a few exceptions to the above, carefully designed for special cases like malloc, where the mapfile for the library has a NODIRECT tag for such symbols. But those are rare. In summary, "direct bindings" are a good thing, and help us stay out of the "DLL hell" the Windows used to suffer :) Gordon _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
