hi gianfranco, there is indeed some reasoning behind this: the ABI (and even API) of libcheck isn't particularily stable, arguably it wouldn't even be desirable for a library like this to have a stable interface: the cost of making it harder to change outweghts the benefits.
because of this, libcheck is shipped as a *static only* library, which means you can still link against it and don't have to include libcheck *code* in your project. the static library is called liobcheck.a, and a typical linker invocation involves "-static" to tell the linker about the fact that you want to link statically. please also note that it is not the target usecase to ever *ship* anything linked against libcheck, which is the usual reason for wanting to link against a .so. regards robert On Fri, Oct 25, 2013 at 02:10:06PM +0100, Gianfranco Costamagna wrote: > Hi developers, maybe do you have a rationale for this, but in ettercap we > have recently enabled tests, and we link our tests with libcheck.so file. > > In debian seems to be this file is deleted upon build, as shown in rules file > rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so.* > rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so > rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.la > > How can we link it if you delete it when building? > > At this moment we are using an embedded libcheck copy, but this solution > isn't the best one. -- Robert Lemmen http://www.semistable.com
signature.asc
Description: Digital signature
