Re: cctbx debian package
On Thu, 26 Jul 2012 00:33:48 +0200
Radostan Riedel <email@example.com> wrote:
> Hi Fred,
> I was thinking about the problems with libann. Upstream is linking additional
> symbols into a shlib and calls it libann. Since the additional code is very
> specific to cctbx I doubt we can get it into ANN upstream. But I think I know
> what we can do. I can patch it so far that using the option "--use_system_libs"
> it will only build a shlib lets call it 'libann_adaptbx' with that additional code.
> It's not so much to change since only only 2 extensions and libspotfinder is
> depending on libann:
the only concern about this is if this modified libann is part of a
public API provided by cctbx. so is it possible to use #include
<cctbx.h> or something else without the header of this modify
for the extension to me this is not a problem you should build a
"private share library" called libann_adaptbx (like noinst_xxx target
with automake) .
If I remember correctly this link the the object of the noinst library
into the library which use it.
If this is not clear for you do not hesitate to ask for a better
> $ grep "LIBS.*ann" **/SConscript
> spotfinder/SConscript: LIBS=["ann","omptbx"]+env_etc.libm
> I'm not sure if libspotfinder is even using any symbols of libann. I remembering some
> warnings from dpkg-shlibdep about unused symbols. But I'll check.
if libspotfinder do not use ann it would be perfect :)
beware dlopen , this can gives thoses unused symbols, just check
> The same could be done for cbflib. The changes here would be even smaller.
> What is your opinion on that?
GPG public key 4096R/4696E015 2011-02-14
fingerprint = E92E 7E6E 9E9D A6B1 AA31 39DC 5632 906F 4696 E015
uid Picca Frédéric-Emmanuel <firstname.lastname@example.org>
GPG public key 1024D/A59B1171 2009-08-11
fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171
uid Picca Frédéric-Emmanuel <email@example.com>