[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Installed libs wrongly used on 64-bit Linux?
From: |
Bob Friesenhahn |
Subject: |
Re: Installed libs wrongly used on 64-bit Linux? |
Date: |
Thu, 22 Jan 2009 14:13:37 -0600 (CST) |
On Thu, 22 Jan 2009, Tim Mooney wrote:
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?
One user (the one with the link to the installed library) used a
Gentoo ebuild and another used a SRPM spec file. Perhaps both of
these use a build root.
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.
It seems that the CentOS user is seeing different issues. When he
runs 'ldd' (as root) on the installed shared library or module, ldd
complains that it is not executable by the user. It seems that the
executable bits are not set on the .so files. However, even after
adding executable bits, ldd reports the same.
These are presumably 32 bit builds on a bi-modal system with a 64-bit
Linux kernel. I notice that the RPM build installs libraries under
/lib/64. Is it possible that the OS will refuse to use 32 bit objects
installed under /lib/64? The dependent executable does execute, but
fails to load any of its modules.
Perhaps the problem is something simple, but the libltdl bug which
discards the error reported by the OS is getting in the way of
diagnosing the issue.
Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/