RPM and shared library support

[Dario Alcocer]

On Fri, May 09, 2003 at 10:02:16PM -0400, Charles Wilson wrote:
> Dario Alcocer wrote:
> 
> > 
> > libz----\
> >          +-librpmio---------------librpm
> > libbz2--/        \                 /  |
> >                   \               /   |
> >                    +---librpmdb--+    /
> >                   /                  /
> >            libpopt------------------+
> > 
> > 
> > Well, from the looks of it, we'll have to have shared libraries for
> > libbz2, libz, and libpopt first before I can release an rpm-devel
> > package.
> 
> I already ship the DLL for libbz2. Unless rpm has its own version of 
> that, too?  If so, you forgot to list it in the first message in this 
> thread.

Sorry, I was unclear. Yes, RPM will use the standard bzip2; it doesn't
require a specially modified build for bzip2.

> > OK, so now it looks like rpm-devel will only need shared libs for libbz2
> > and libpopt.
> 
> libbz2 -- already there
> libpopt -- already there (unless you *need* the 1.7 version)

RPM uses poptSaveInt and poptSaveLong, both of which (evidently) used to
be static functions in popt:

    alcocer@devpc ~
    $ nm --defined /usr/lib/libpopt.a | grep -w _poptSaveInt
    000010c4 t _poptSaveInt
    000010c4 t _poptSaveInt

    alcocer@devpc ~
    $ nm --defined /usr/lib/libpopt.a | grep -w _poptSaveLong
    0000105c t _poptSaveLong
    0000105c t _poptSaveLong

However, in version 1.7 they're public (non-static) functions.
So, I'm stuck until popt 1.7 is done.

[Well, actually, that's *not* correct, because I could try getting popt
1.7 to build using the new libtool in /usr/autotool/devel. I imagine
I could copy the /usr/autotool/devel/bin/libtool into my popt source
directory and build it, right? Maybe I'll try this.]

> > I don't quite understand this comment; do you mean that we don't need
> > rpm-devel? 
> 
> No, of course we don't NEED rpm-devel.  Honestly, we got along for years 
> without rpm. <g>  AFAIK, there are very few apps out there that link 
> against librpm -- apt-rpm is one of the few.  Most "rpm wrappers" that I 
> know of COULD have been architected to link against librpm -- but 
> instead simply fork/exec the rpm executable.

Yes, I wish that were the route that the apt-rpm folks had taken.
Launching via fork/exec makes it easier to aggregate functionality into
a working application.

> So, *except* for apt-rpm, librpm-devel is of limited utility in the 
> grand scheme.

Yes, I would agree with you.

> I say this not to discourage you, however 

On the contrary, your approach to the whole notion of RPM in Cygwin has
*encouraged* me. Actually, I thank you for not shooting down the idea
out-of-hand.

> -- I'm a stickler for completeness myself. I wouldn't consider the rpm
> set of packages complete until it rpm-devel is published. But I, me
> personally, I'm not in a huge hurry.

Absolutely, I can see your point.

> > Actually, I'd like to see it released soon myself. I'm deferring
> > work on an apt-rpm port until the libbz2/libz/libpopt shared lib
> > situation is resolved for rpm-4.1. Does strategy actually make
> > sense?
>
> Deferring apt-rpm? Sure. Waiting on libbz2/libpopt? I dunno, what're
> you waiting for? cygbz2-1.dll is part of the libbz2_1 package, while
> libbz2.dll.a is part of the bzip2 package.

This is probably a very dumb question, but what's the difference between
cygbz2-1.dll and libbz2.dll.a (other than cygbz2-1.dll being a shared
library DLL, and libbz2.dll.a being in import library?)

> And, of course, popt is already available in shared form -- but it's
> version 1.6.4. I dunno if you're insisting on 1.7...

Oh, *I* wouldn't insist on anything (I can't, I'm not mean enough <g>),
but evidently RPM *does* insist on popt 1.7.

> That leaves the libz question -- and Nicholas has promised me lots of
> documentation etc. so we'll see.

Well, I think we can sidestep modifying libz; IIRC, according to Jeff
Johnson's message, the 16MB buffer patch used by RPM only buys them a
~10% speed increase, so we can probably do fine with a standard libz
build.

To summarize: it looks like RPM can use the existing bzip2 and zlib,
will need an upgrade to popt 1.7, and will need a new Berkeley db4
library.

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
alcocer@helixdigital.com -- http://www.helixdigital.com