rebuilding libbonobo after removing /usr/lib64 on pure 64 bit system

Arnie Stender astender at
Thu Sep 28 17:04:46 PDT 2006

Hash: SHA1

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/, which probably references /usr/lib64/
> 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
> thing.
> -- 
> Dan
Hi Dan,
	It so happens that when I got rid of /usr/lib64 I copied its contents
to /usr/lib first which I think included the 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/ 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. ;-)

Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the blfs-support mailing list