Open GoogleCodeExporter opened 8 years ago
Thanks for the patch.
But what I am wondering is that whether or not we really need to link all the
dependency of libgnomenu into itself.
I thought we should specify these dependencies in the package config files, and
let
the user of libgnomenu to link these dependencies into the final executable.
Otherwise we run into the overlinking problem.
Refer to issue 361. I am always confused with these linking issues.
Original comment by rainwood...@gmail.com
on 21 Oct 2009 at 4:23
actually that's touching details of how dynamic linking is done that I could
not detail to you for a lack of
precise understanding. Reading the overlinking mandrive wiki, I understand that
in the given example, libpng
must link to libz but not emacs as emacs doesn't use libz directly and hence
couldn't care less if libz
changes or not as long as libpng still works. To avoid extra libs from
polluting your lib, you can only stab
upstream until they fix their pkgconfig but you still have to ensure that your
lib is fully linked to the libs it
needs. I hope I'm clear :)
Original comment by eva...@gmail.com
on 21 Oct 2009 at 9:31
I think for the libraries on which libgnomenu depends, the pkg-config files are
already fixed.
And in this case we should specify the dependency in .pc files rather than
linking
against all dependencies. A recent pkgconfig should be able to make use of these
tags in libgnomenu.pc.in .
However it is becoming cubersome if any of the other components in the same
project
is depending on libgnomenu: we have to memorize and copy every dependency into
every
component.
My opinion:
I prefer writing the dependencies in libgnomenu.pc to linking libgnomenu
against its
dependency, UNLESS we turn libgnomenu to a noinst static library.
Original comment by rainwood...@gmail.com
on 25 Oct 2009 at 6:24
Original issue reported on code.google.com by
eva...@gmail.com
on 17 Oct 2009 at 4:25Attachments: