Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3B42A662.1090200@ece.gatech.edu> Date: Wed, 04 Jul 2001 01:15:14 -0400 From: "Charles S. Wilson" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Soren Andersen CC: Cygwin List , michael-ring AT t-online DOT de Subject: Re: cp error -- oh the great sanity of *nix tools?!? References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20010624204747 DOT 024b8828 AT pop3 DOT cris DOT com> <000601c0fdad$3957d180$36ab313f AT sigmund> <3B37F924 DOT 7080101 AT ece DOT gatech DOT edu> <000501c0fdf2$54407fc0$b0aa313f AT sigmund> <3B383626 DOT 7070608 AT ece DOT gatech DOT edu> <002801c100f0$ed74f260$b0aa313f AT sigmund> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soren Andersen wrote: >> Sure. For starters, gdbm is GPL, and GNU (FSF). BerkeleyDB is NOT. >> There are certain license restrictions -- which should not cause any >> issues with cygwin, but let's be honest: there IS and always will be a >> certain bias *against* non-GPL (free-speech) software in this forum. > > > Sure, I am aware of that. I like to forego the most heated of the religious > debates when the main point is to talk about getting things built. For me > the point that BerkeleyDB has a license which *doesn't* pose problems with > Cygwin is the most immediately significant one. Let's put it this way. I wanted to port CVS. CVS can use either BerkDB or GDBM(ndbm-emulation-mode). I preferred, for "religious" reasons, to use GDBM -- to the extent that I took heroic efforts to get CVS+gdbm(ndbm-emulation-mode) to work on FAT disks. So I ported and support gdbm. Not BerkDB. >> The binary, precompiled package in contrib/perl/perl-5.6.1-1.tar.gz does >> not include BerkDB support. That's what most people are going to use; >> hence: "the official Cygwin perl is built without db support). > > I don't have the wide knowledge sufficient to have known what most people > are going to use, and I wasn't sure you weren't using the `db' generically > here -- now I think its confirmed for me that you were. No, I mean BerkDB support was not included in the official Cygwin perl binary. GDBM db support IS included in the official Cygwin perl binary. > But this leaves me a > little confused, further, to wit: isn't gdbm commonly downloaded/installed > by Cygwin users, and so would be available (just FYI I didn't -- as one > would certainly hope! -- have to do anything special to get Perl to find > libgdbm)? Or is gdbm just very newly added to the standard Cygwin distro > packages? Anyway .. > > >> However, if YOU have the BerkDB library on YOUR system, and download >> contrib/perl/perl-5.6.1-1-src.tar.gz and BUILD it yourself on your >> system, YOUR version WILL have BerkDB support. >> {...} Yes, the *source code* of perl, as ported to cygwin, does support >> BerkDB if you have it. Thus, the README talks about BerkDB support >> However, the particular binary that is installed by setup doesn't include >> that capability. > > I understood this :-). > >> One other thing -- Michael's db3 port was dll-ized. My db2 port (and >> yours, I suspect) are static lib only. > > Yes, I built a static lib. > > > [Soren, regarding finding BerkDB on Charles' site] > >> I dunno. I really don't have much time to tweak that site anymore, now >> that I (and others) have repackaged almost everything of interest from >> CygUtils so that they're now installed by setup.exe and are part of the >> "official" distro. > > It has been a great help, anyway. > >> Interpretation: >> "The official perl doesn't have the extensions I want. Some of these >> desired extensions depend on external libraries that aren't official. >> Therefore, the official perl won't get my desired extensions until the >> external library is "officialized" -- and then the perl maintainer will >> need to rebuild perl to use the newly official library, so that my >> desired perl extension is built and included in a new perl package. But >> he might not ever do that and then I'll never get my desired extension >> even if I manage to get the necessary libraries officialized. That makes >> me sad." > > > Well, that's a pretty good summing-up. > > >> Response: > > {... a lot, then: } > >> So, to sum up: if you want the "missing" blessed extensions to be >> included in the official cygiwn-perl, then help make the required >> libraries (and functionality) a part of cygwin. Port & support BerkDB. > > > Hmm. Interesting. What I meant about "authors not being allowed to finish > writing their software" was that the version of BerkDB that many people are > using with DB_File is, AFAIK, N.xy, where N is probably 2 (because the 1.xx > code is *really* old by now) and x is probably 7 and y might (as well) be 7; > and AFAIK this goes for the wider Perl community, _not just > Cygwin_ -Perlers; so why does Cygwin have to have stricter standards than > are common in the Perl user community? I mean, if Eric has already done this > work on BerkDB3 I can see the reluctance that might exist to 'waste' that > effort, but *that aside*, theoretically, why cannot the "standard BerkDB" > that is used with Cygwin and Cygwin-Perl be 2.77? You're not listening. There is NO "standard BerkDB" for cygwin because NOBODY has packaged ANY version for official inclusion in the distribution and promised to be its maintainer. I (sortof) ported 2.7.7 at one point on my cygutils website -- but I never took the extra step of dll-izing according to the "new" scheme or packaging it up for official inclusion. I am not willing to take on, port, or maintain another package. I'm swamped. Also, since many many changes have occurred in cygwin since I did that ancient port, I'm no longer sure my "port" even compiles anymore. And, it certainly doesn't do DLL-building "correctly" (where "correct" == current method as used in readline, jbig, tiff, jpeg, zlib, png...) As I said earlier, ANYONE is free to take my port of 2.7.7 and update it to follow the new setup.exe-based packaging standard, and update the DLL-building stuff to "conform" -- and ask that this NEW port of 2.7.7 be included in the distro. (Except that we're currently in a no-new-packages freeze until the changes in setup.exe settle down) However, let me caution against that: Sleepycat no longer supports or recommends the 2.XY series of BerkDB software. Therefore, if one is to go thru the effort of porting and testing and maintaining and packaging a new "BerkDB" package, doesn't it make sense to do all that to the current code base? e.g. 3.XY ? About a year ago, Michael Ring and I bounced several versions of db-3.1.17 back and forth. He promised to finish it up and propose it for inclusion in the official distro, but he seems to have dropped off the list a while back. (Michael, are you there?) I still have the most recent version we cobbled together; this version "db-3.1.17-2" obeys the cygwin packaging standard and naming conventions, there's a -DDB_STATIC flag for static linking, etc. (Although Sleepycat released 3.2.29, the very next public release after 3.1.17, on Jan 24, 2001...sigh) Also, the last message I got from Michael on the subject cautioned about conflicts between db1 and db3, and mentioned that he had come up with a workaround in which he created implibs for both versions (from the same 3.x.y sourcecode?) So, I'm not at all confident that the "3.1.17-2" package that I have is "good". Anyway, I never did see Michael's post-2 updates. Michael, you wanna chime in here? > Is it because BerkDB3 > offers so much more in the way of progress, improvement, *and because* > Cygwin developers are going to want it for more than just the 'blessed' Perl > module DB_File? (you see, I am such a monomanaical Perler that this hadn't > occured to me until now). There is no "BerkDB" policy. Nobody has stepped forward to support ANY version of BerkDB, so it hasn't been an issue. > And .. if that *weren't* the case -- if making > 2.77 the "official" lib for Cygwin was countenanced -- what degree of > "support" would we be talking about? It's a very stable thing that's been > around a long-ish time; I think of it as just 'doing what it does' without > much fuss. And is DB_File going to change? AFAIK its also been very stable > for a long, long time. The module and the lib sort of go together closely in > a case like this, I thought, and are both very stable (if not stagnant ..), > so isn't this "finished"? If there are "bugs" (not special "Cygwin-specific > bugs") in this (and I suppose there _always_ are ..) aren't they just going > to stay there? This is what I meant by "being allowed to finish writing > [some software]." Some of the changes can be unrelated to the base package's code. For instance, what if libtool suddenly supports building dll's "cleanly" -- but requires all dll-ized packages to be rebuilt with certain changes? Or worse, about 18 months ago the decision was reached that dll's on cygwin should be named "cyg.dll" -- requiring me to recompile ALL of my dll-ized packages to follow that naming scheme. Fortunately, that kind of disaster doesn't happen often. Sure, db-2.7.7 may not change, but external events can force a maintainer to rebuild the package on occaision. (See my recent slew of updates to dll-ized packages, so that -DALL_STATIC can be used as an alias for -D_STATIC when linking client apps statically) > See, I am too ignorant of what some of the terms you are using mean to you > and other Cygwin folk and those in parallel positions to yours. I do know > that: I don't think I am qualified, frankly, to offer user-level support on > a database lib, so what Cygwin apparently wants as a package (not just a > one-off "Makefile Makeover" but that AND a developer to go with it ...) > it cannot get from me. If I *could* do it, I would, but it isn't just a > matter of personal available time (which is also very scant for me), it is a > matter of capability/qualifications. I would need a LOT of hand-holding by > somebody at Cygwin, at the least. Well, you never learn by sitting on the sidelines. I only learned by diving in (without checking the water's depth, as it turned out...) >> The "regular" extensions can be built using the CPAN shell. > > > Yes, the regular extensions are no problem, CPAN is no problem (Uhh, well, > basically, uhhh, actually, it hasn't been able to build a lot of extensions > for me just recently and I don't know why -- parse errors in the > Makefile.PLs that don't show up, when I resort to building manually ... > arrgh). This is a common complaint. I think there may actually be a (non-newbie-related) bug in there somewhere. Perhaps when Eric returns he can take a look... > > Anyway, I wanted to get back to you and the List with some comments and > clarifications since I sounded off fairly loudly for a moment there. I feel > that I have learned a lot from your substantial reply, and so thank you > again, Charles. I appreciate the time you took to write it. No prob. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/