In regard to: Installed libs wrongly used on 64-bit Linux?, Bob Friesenhahn...:
Starting yesterday I am hearing of GraphicsMagick 1.3.3 users who built
from source code and found that the installed loadable modules are
depending on a previously installed lesser-version GraphicsMagick
library rather than the one in the build tree. Both of the reporting
users are using a 64-bit Linux (Gentoo and CentOS) which supports both
32/64 bit libraries. The GraphicsMagick build was apparently a 32 bit
build. GraphicsMagick 1.3.3 uses libtool 2.2.6.
One user reported that building and installing twice "solves" the problem.
I've run into the exact same problem with various libtool versions (both
1.5.x and 2.2.x) over the years, for several different packages. I do
most of my building on Solaris 10, and generally build only 64 bit. I
can also confirm that doing an install of the package and then another
rebuild addresses the problem.
In my case, I'm 100% certain that the problem relates to the fact that
I'm using a build root while packaging the software (RPM). Are both of your
users doing the same?
I'm almost certain the problem is that there's a
/usr/local/lib/64/libfoo.la
from version 1.0 of package "bar", and when I'm building "bar" version 1.1
and it builds version 1.1 of libfoo.la, during the relink phase of make
install, bar is being linked against the version 1.0 libfoo.la that's in
/usr/local/lib/64, rather than the version 1.1 libfoo.la that was just
installed in e.g. /tmp/build/bar/usr/local/lib/64.
Tim
--
Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
