On Tue, Jan 12, 2010 at 01:45:07AM +0100, Kevin Kofler wrote:
> Charley Wang wrote:
> > Please note that many of the packages may be failing because of a few
> > DSO's. Further exploration is needed to evaluate this possibility so
> > we can apply one patch to the source of the problem instead of dozens of
> > superfluous patches. We also need (and would appreciate help with) the
> > linking of failed build logs to their package owners.
> And how would you fix that in the DSO other than by adding a .la file (which
> is against our packaging guidelines) or a linker script (which basically
> amounts to the same) to force the extra -l flag? Linking the DSO to the one
> providing the symbols is not enough due to the very change which is causing
> the problems.
According to notting and the experimentation that I did after the FESCo
meeting, the shared libraries bring in any libraries that they depend on.
However, if the application linking to the shared library also requires the
third shared library but doesn't explicitly link it then the link will fail.
libfoo requires libbar.
This is used to link: gcc -o libfoo.so -lbar foo.o
libfoo.so contains the dependency on libbar.
/usr/bin/baz depends on symbols in libfoo but not libbar.
This can be used to link: gcc -o baz -lfoo baz.o
The link succeeds and the resulting /usr/bin/baz links to both libfoo.so and
libbar.so as expected.
/usr/bin/baz depends on symbols in both libfoo and llibbar
This fails to link because of missing libbar: gcc -o baz -lfoo baz.o
This succeeds: gcc -o baz -lfoo -lbar baz.o
Roland, can you clarify that this is indeed how things are supposed to work?
Also... it took me quite a while to come up with the command line flags on
F12 that would allow me to test this (I think I had to get gcc to show me
the linker invokation it used and then run those linker lines with my
modifications), can you tell us what command line flags let us test out the
differences in behaviour on F12?