Some library and packaging advice please?

[Ben Scott]

On Wed, May 28, 2008 at 12:54 PM, Neil Joseph Schelly
<neil at jenandneil.com> wrote:
> I'm trying to build a Kolab server ...

  Never so much as touched it, but...

> The environment I'm working in is Debian, but the versions of Kolab in Debian
> (both etch/stable and lenny/testing) are older than I want to use ...

  According to the Kolab web site, they've got their own binary
packages available for Debian 3.1.  Have you tried those?  Or is that
not the Debian release you're using?

> Those RPM files are distributed with a script to setup a root folder
> (/kolab) and compile/install all those source RPMs into it.  Everything lives
> in this neat little bubble with libraries all statically compiled into the
> binaries, never leaving the confines of /kolab.
> ... glibc is not statically linked ...

  Wow.  That's... um... that's... interesting.  All the drawbacks of
pre-packaged software, with all the drawbacks of building from source,
and all the drawbacks of static linking with all the drawbacks of
dynamic linking.  Are you sure OpenPKG isn't really a plot by
Microsoft to make *nix software look bad?

> When the process that is starting is a binary in the /kolab bubble,
> it has libldap_r.a compiled into it statically, albeit a slightly different
> version.  This causes a duplication of all the library functions
> in the run-time process now.

  Yah.  Specifically, I believe what happens is that statically
compiled functions are not seen by dynamic libraries, nor vice versa.
So anything in the static binary that linked against the static
function calls will continue to use those.  Any dynamically loaded
libraries will load their own libraries.  That will duplicate the
code, as you suggest, but the calls shouldn't invoke each other.
Basically, once a  function from a dynamic library gets called, any
further subroutine calls will come from the dynamically loaded world.
It should never "go back" to the statically compiled functions (unless
something passed a function pointer for a callback).  Of course, once
the call to the dynamic function returns to the static binary,
statically compiled code can be invoked again.

  I'm going to guess that what's happening is that data structures
from different versions of the libraries are being passed around
between all these different function calls.  Yikes.  No wonder it's
crashing.

> Has anyone tackled problems like this before?

  Not exactly.  But:

  SRPMs are just an archive of source packages, optional source
patches, and a control file (the .spec).  The spec file's %prep and
%build sections detail the commands needed to unpack the sources,
patch them, configure them, and build them.  You should be able to
unpack the SRPM and look at the spec file to extract the build
sequence, and then build a properly integrated binary against that.
It looks like they're using configure, so you might even be able to
just use standard options for everything.  (Although it wouldn't
surprise me to hear they've got hard-coded paths in their source, if
they're using such a brain-damaged package system.)

  From what I can see, there don't appear to be many original packages
in the Kolab distribution -- it's mostly third-party stuff they're
including for dependencies.  So, if you apt-get all the dependencies
from the Debian repository, you'll hopefully only have to do that for
a couple of Kolab-original packages.

-- Ben