[CentOS] Source RPM issues. Mismatched Libs?

[Nicolas Thierry-Mieg]

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.

Regards,