rebuilding libbonobo after removing /usr/lib64 on pure 64 bit system
astender at aagstender.org
Thu Sep 28 17:04:46 PDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Dan Nicholson wrote:
> Sort of. Libtool places .la files in the filesystem that have info
> about the associated library (.a and .so). So, libtool is pulling in
> /usr/lib/libpopt.la, which probably references /usr/lib64/libpopt.so.
> Libtool then fills this in on the linking command line, thinking this
> is where it should try to link to. I'd bet a dollar to donuts that
> you'll find the hangups in the .la file for libpopt.
> Now, some people just completely delete these .la files as they seem
> to cause nothing but trouble. RedHat does. I'm not exactly sure what
> the benefit of keeping them is. I don't really know the internals of
> libtool. During the build of libraries within the source tree, they're
> quite useful. Once they're on the / system, though, there's no reason
> why the linker won't just find them on it's own and do the right
It so happens that when I got rid of /usr/lib64 I copied its contents
to /usr/lib first which I think included the libpopt.la file. The reason
I did that was because (I think) the version in /usr/lib64 was newer. It
makes sense that it would have a reference to /usr/lib64 since that is
where to was installed but when I looked at the file in
/usr/lib/libpopt.la I found three lines relevant to this conversation.
# Please DO NOT delete this file!
# It is necessary for linking the library.
This must be a shot at self preservation. And more relevant:
# Directory that this library needs to be installed in:
Does the comment mean that "it was in /usr/lib64 and SHOULD BE in
/usr/lib" or does it mean "you can link to this lib in /usr/lib"? I'm
going to try renaming the file and try the compile again. Stay tuned to
the ongoing saga. ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the blfs-support