The problem discovered about libgii not linking libgg during a build on
a system with no prior libgii installed is much worse then initially
diagnosed. Apparently most everything fails to be relinked by libtool
during installation to a packaging directory.
I've researched this quite a bit and found that it's a bug with libtool
working with interdependencies and installing to a packaging directory.
Effectively libtool does some relinking to place the libraries in the
final resting place in the system lib directories and can't find any of
the dependent libraries because they aren't in the system directories -
they are in the packaging directory. If you have an old build already
in the system lib dirs then the new version being packaged will have its
relink done against the old library - very bad.
This is causing fits for Debian packaging:
http://www.linuxarkivet.nu/mlists/debian-devel/0105/msg02183.html
http://www.geocrawler.com/mail/thread.php3?subject=install+phase+fails&list=404
This should also cause serious problems for RPMS as well - it is for me.
My guess is that most people don't notice it because they don't do clean
room builds and installs. It wouldn't surprise me if RedHat is even
suffering the problem unknowingly.
I'm fixing things.
<pause>
committed - try that.
(evil, nasty, bad, necessary, very important libtool that we can't live
without ;^)
PS. I was partially wrong with the way I was fixing things with
libtool. In the future don't ever link against anything in .libs
subdirs and always try to link against *.la libtool files. You can see
examples of this in the Makefile.am's:
in libgii/gii/Makefile.am:
libgii_la_LIBADD = $(top_builddir)/gg/libgg.la $(SELECTLIBS)
These *.la files are hints to libtool about how to link against
libraries and do some of it's masking of library building and linking
complexities from developers.
PPS. I'll be updating other packages outside of ggi-core with new
configure.in files shortly.
--
Thayne Harbaugh
