This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: cp error -- oh the great sanity of *nix tools?!?
previously "Charles S. Wilson" wrote Re: cp error -- oh the great sanity of
*nix tools?!?
> >>It's not a perl dependency (that is, you CAN build perl WITHOUT Berkeley
> >>db.
> >>the "standard" cygwin-perl package should only depend on
> >>"standard" cygwin packages. Currently, gdbm IS, but db is not, so when
> >>Eric builds his perl package on a stock cygwin system, the db .pm files
> >>which are included in the perl-5.6.1 source code are not used ---
> >>because his stock cygwin system doesn't have the db lib.
Soren Andersen:
> > The current Cygwin Perl seems to find and build with the gdbm lib just
fine.
> > Maybe someone would like to address the Q of comparison of gdbm with
bdb, in
> > this connexion. I am just learning many things.
> 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.
> >>In fact, the "official" cygwin perl is built without db support).
> > {...} And the docs which I
> > carefully printed out and studied for hours before and during the build
seem
> > to me to suggest that it *is* "standard" to build whatever *can* be
built of
> > the set of extensions located in "ext/" under Perl's top srcdir.
> 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. 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:
> > {...} OTOH I *did* see one _really
> > strange_ phenomenon: I first downloaded the source/read all the docs,
set
> > things up, and built -- in Win98. And it went to completion without so
much
> > as a chirp. Then I switched over (rebooted) into NT and that system's
own
> > Cygwin (pretty updated as well) and built from pristine source, in its
own
> > new dir -- but it *didn't* go cleanly until I fixed some things -- the
most
> > major of which indirectly concerned a bit of an asm file include. Did
the
> > inscrutible combo of Cygwin, my GCC, and the software's `configure'
somehow
> > decide to do something different just based on being on NT vs 98??? Such
a
> > thing seems very unlikely, does software EVER do this?
Charles:
> It could happen, especially if your NT system uses NTFS rather than FAT.
AHHH! Thank you!!
> See, configure will detect the capabilities of your system -- which
> are DIFFERENT under NT and Win9x -- and based on that, turn on certain
> #defines and turn off others. This can lead to entirely different code
> being compiled on NT vs. Win9x, even under cygwin.
Very very good to have that clear. OK.
[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.
> > {...} Just how "supported" do things have to be? Perl is a special
> > case. Does this Cygwin policy assume that all software authors will
> > indefintely continue to rewrite their code? Is nothing ever allowed to
be
> > substantially just "finished"?
> I'm not sure I understand what you're driving at in the preceeding two
> paragraphs. I assume the following interpretation, and will respond to
> that:
> 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." <g>
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? 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). 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]."
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" <g> 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.
> Help add IPC functionality to cygwin1.dll (but NO peeking at cygipc --
> copyright issues).
LOL! Hah, I would LOVE to be that proficient a hacker. I would certainly do
it for free if I knew how to start. I am still just barely competent enough
to fix small macro problems in C-sources, for example; the source syntax
*itself* usually makes my eyeballs cross and spin around in their sockets
<g>. I really really really am NOT a C programmer (no training but what
little I have provided myself from books).
> 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).
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.
Best,
Soren Andersen
--
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/