[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 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



Quoting Michael Schwendt <mschwendt tmp0701 nospam 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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]