[CentOS] Source RPM issues. Mismatched Libs?

[Johnny Hughes]

Nicolas Thierry-Mieg wrote:
> Johnny Hughes wrote:
>> Justin Bull wrote:
>>> Hello,
>>>
>>> I am having some issues with the installation of the Icecast2 software
>>> on my CentOS 5.3 x64 machine. I am attempting to install from a source
>>> RPM provided by the developer.
>>>
>>> Upon executing:
>>>
>>> # rpmbuild --rebuild icecast-2.3.2-0.src.rpm
>>>
>>> Normal compilation takes place until the following error is thrown out:
>>>
>>> /usr/lib64/libxslt.so: undefined reference to `xmlXPathContextSetCache'
>>>
>>> I've done some research and found others have a similar issue. It
>>> appears this is only isolated with CentOS 5.x x64 builds and,
>>> according to the Icecast2 developer, is due to a mismatch between
>>> libxml2 and libxslt.
>>>
>>> My machine is a brand new install and is updated from the official
>>> mirrors. libxml2-devel and libxslt-devel are installed and are at
>>> their latest version (2.6.26-2.1.2.7.x86_64 and
>>> 1.1.17-2.el5_2.2.x86_64 respectively at the time of this writing).
>>>
>>> For anyone who is interested in reading up on this, here are the
>>> Icecast2 threads related to this issue:
>>> http://icecast.imux.net/viewtopic.php?t=4851
>>> http://icecast.imux.net/viewtopic.php?t=6506
>>> http://icecast.imux.net/viewtopic.php?t=6210
>>>
>>> I do apologize if I've made any formating mistakes and/or incorrect
>>> posting etiquette to the mailing list, as it is my first time using
>>> one.
>>>
>> OK, all those people are mistaken.
>>
>> Your issue is that you have i386 packages installed as well as x86_64
>> packages installed and the linker is looking in the wrong place.
> 
> Actually it *wants* to look in the right place, as shown by
> ld --verbose | grep SEARCH_DIR
> 
> But it's probably being forced to look in the wrong place by a 
> -L/usr/lib switch. Bug in the Makefile, perhaps in autotools as this 
> crops up often (I don't use autotools so not sure).
> 
> 
>> If you want to build x86_64 packages, you will have to do an install
>> that has only x86_64 packages and no i386 packages.
> 
> Or let the linker do its work without interfering with its builtin 
> search path. I think that would be the proper fix, rather than the 
> workaround of not having anything in /usr/lib.
> 

Well, that may be, however I would always recommend a clean build
environment for all builds (not just this one).  With mock available to
build a chroot which contains only the exact required packages to build
the code in question, I see no reason not to use it all the time when
building.  This prevents stray links to things you are not interested in
anyway.

That is how all packages are built in the fedora-rhel-centos world right
now.

In practice these kind of issues always come up when there are lots of
i386 packages on an x86_64 machine, so why not build all code in a pure
chroot?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20090827/268859eb/attachment.sig>