>> 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.