[lsb-discuss] lsbappchk DT_NEEDED

Wichmann, Mats D mats.d.wichmann at intel.com
Thu Jul 12 09:34:01 PDT 2007


>> We might require that all LSB applications should be built with
>> "--as-needed" linker option (and make lsbcc use it). This
>> should ensure no libraries are placed in DT_NEEDED that are
>> not directly called by the app. But I wonder why people do not
>> use this option in wide practice - are there any reasons other
>> than the option is not active by default?
> 
> Most likely, people don't know about it.
> 
> It turns out in complicated situations --as-needed may not
> do the right thing, at least according to how this was
> explained to me just a few days ago.  I have to find the
> reference again, I may be remembering/understanding wrong.

Okay, I have some more information now.  It's not that
--as-needed itself is buggy, but it may expose problems
in builds that are not completely correct.  Of course,
it's easy to say "well, fix the builds" but it's not
necessarily clear that all the components involved are
under the developer's control.  

Undefined symbols (link time or run time):  --as-needed does
computations based on references in the executable, but if 
there's an undefined symbol in a /library/ (which is perfectly 
allowable when the library is constructed), these will not 
be tracked so the dependent library, even if listed on the 
command line, may be removed by the linker anyway (will be
removed, if the executable itself does not reference anything
in that library). The library actually has to be built 
depending on the other library (DT_NEEDED). This could be 
quite confusing if the option has been supplied "silently" by
lsbcc or if developers don't know about the option at all.

What happens if the library that causes the problem is not
a library that I build or have control over?

Using --as-needed also makes the order of things appearing
on the link line important, as in this simple example pulled
off the web:

$ cat foo.c
#include <gmodule.h>
int main()
{
  return g_module_supported() == 0;
}
$ gcc -Wl,--as-needed  -I /usr/include/glib-2.0 -I /usr/lib/glib/include
\
-lgmodule-2.0 -lglib foo.c
$ ./a.out
./a.out: symbol lookup error: ./a.out: undefined symbol:
g_module_supported


At the time gmodule-2.0 is seen, there has been no reference
to it, so it's thrown away. Putting foo.c first fixes this...

Of course, making --as-needed default is a good way to flush
out problems, but I wonder if we wouldn't end up irritating
people by doing this.  I'm open to thoughts on that, perhaps
it isn't a problem.




More information about the lsb-discuss mailing list