rpms/libsvm/devel libsvm-2.85.patch, NONE, 1.1 log, NONE, 1.1 .cvsignore, 1.2, 1.3 libsvm.spec, 1.10, 1.11 sources, 1.2, 1.3 ChangeLog, 1.1, NONE libsvm-2.84.patch, 1.1, NONE

[dchen at redhat.com]

Quoting Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de>:

> On Mon, 4 Feb 2008 03:14:40 -0500, Ding-Yi Chen (dchen) wrote:
>
>> Author: dchen
>>
>> Update of /cvs/pkgs/rpms/libsvm/devel
>
>> +%define libdir_libsvm %{_libdir}/libsvm
>
>> -%post -p /sbin/ldconfig
>> +%post
>> +/sbin/ldconfig %{libdir_libsvm}
>>
>> -%postun -p /sbin/ldconfig
>> +%postun
>> +/sbin/ldconfig %{libdir_libsvm}
>
> Seeing that these changes have been applied to F-8 and F-7 already, would
> you please explain what unusual things you try to achieve here?
>
> Note that you move the library out of the linker's search path.
> Even if one adjusted the search path, it cannot be linked against,
> because libsvm.so is not available. And now it's not in the run-time
> linker's search path either. Running ldconfig like above is wrong in
> that case. Anything that would run ldconfig without your custom args
> would remove libsvm* from the cache again. Further, the package
> "Provides: libsvm.so.2" nevertheless which is wrong, too, as the
> library is located in a private path and not found by default. The
> example program and the tools don't link against the library, btw.
>

Hi Michael,

I used to think that the sub-directories of /usr/lib are merely from 
organizing
libraries. Thanks for pointing out that they do not served as this purpose.

The upstream built everything statically, therefore the example programs and
tools do not link to the libs.
Anyway, I will rebuild them using these library and address the issue 
you arise
ASAP.

Regards,
Ding-Yi Chen