This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: RPM and shared library support
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