This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RPM and shared library support


alcocer@helixdigital.com wrote:
Chuck Wilson has suggested[1] that RPM dynamically link to the Berkeley
DB database shared library; I imagine this would go for zlib, too.

Well, perusing the RPM mailing list archive, it turns out that it's a
little more involved. According to Jeff Johnson, RPM purposely uses
modified versions of zlib, db4, beecrypt and libelf, which is why the
libraries are embedded in the RPM tarball distribution[2].

In particular:

  * zlib uses 16MB uncompress buffer for RPM speed-up.
  * zlib includes the 'rsync ready' patch.
  * db4 compiled with --with-uniquename=_rpmd.
  * beecrypt has "a home-rolled, Knuth based, gcd mod invert function to
    work around a bug in DSA signature verification."
  * RPM uses libelf gelf_XXX() API which has been widely deployed.

Bottom line, folding in subordinate shared library support to the
upstream RPM 4.x release might take a while. So, the question
becomes: can we move on to shared RPM development libraries
(/usr/lib/librpmdb*.dll) without support for subordinate shared library
support?


I've already done it (modified the 4.1/4.2 builds to use external shared libraries). The plan is to add rpm's enhancements to each of those packages. The only thing we need to do is convince CGF to merge the zlib patches, which I see as "harmless" additions anyhow, and we should be set. There is no reason to distribute redundant dlls, especially since it sort of contridicts the point of using dll's in the first place.


I've already had one-on-one conversations with Jeff Johnson, and he's filled me in on the nitty-gritty. As I stated before, there's no rush and I think we can get shared lib support in the next version of rpm.

The main problem I see is the fact that that damn Ulrich Drepper forked libelf into his bastard "elfutils", which use an older libelf and in which libtool was forceably removed from the build. Furthermore, he has the audacity to state on his webpage that he doesn't give a f**k if elfutils works or not in other OS's, he's only going to target Linux and the rest of us can be damned as far as he is concerned. Unfortunately, this is what is currently being used in RPM 4.2+, so it is quite a bit irritating, to say the very least. And if you don't know, Ulrich is the "self-appointed" glibc tyrant/dictator, so trying get him to swallow upstream patches for other OS's/Platforms which "he doesn't like" is about as effective as punching a brick wall. You see, he has delusions that his elfutils will replace binutils, so you can obviously get a sense of the ego trip he is on. (Sorry for the rant, but he's really rubbed me the wrong way w.r.t. his continuous mips bashing...)

Anyhow, it might take some effort to get elfutils working, but hopefully it won't be too difficult.

Cheers,
Nicholas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]