cp error -- oh the great sanity of *nix tools?!?
Charles S. Wilson
Tue Jun 26 00:13:00 GMT 2001
Soren Andersen wrote:
> The Illustrious Charles S. Wilson wrote Re: cp error -- oh the great sanity
> of *nix tools?!?
>>>irrelevent to Cygwin users (at least to those who might want to compile
>>>their own Perl from source), since it is a Perl dependency.
>>It's not a perl dependency (that is, you CAN build perl WITHOUT Berkeley
> I can drink coffee without sugar too -- that doesn't mean I like it :-).
> IMO, hair-splitting -- when talking about something as large as Perl. If
> it's a dependency for *me* then it might be for x% of other users, and those
> are the folks whom I'd like to benefit. We define our own goals/needs, no?
Yes, but 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.
Conversely, since a stock cygwin system DOES have the gdbm libs, the
gdbm .pm files ARE used. My suspicion is, if somebody officially ports
db2 (and db1-compat, and probably db3) and supports them AND they get
included in the official cygwin dist (*) then the next perl package
released after that will magically have the db stuff built in.
(*) not likely to happen soon given the current moratorium.
> 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.
disagree? Then mention Red Hat's dual-licensing scheme for cygwin
itself and watch the flame war begin.
Oops. Now I've done it.
>>In fact, the "official" cygwin perl is built without db support).
> Really? I didn't look at my binary package-installed CygwinPerl for this, I
> just looked at what happened easily on saturday's quick and dirty first
> building of my homemade CygwinPerl from Cygwin source. 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. So, I
> suggest that this is a matter of opinion -- and yours carries weight with me
> and I welcome hearing it, but I hope you in turn can hear mine, even if it
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). 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
>>OTOH, you can build your own perl WITH Berkeley db support if you so
>>desire, and if you do so, the most recent version of Berkdb that *I*
>>have verified to work with a ccygwin port of perl is, in truth, 2.7.7.
>>(I vaugely remember that Michael Ring was working on a cygwin port of
>>db-3.?.?, and that he *did* get it to work with cygwin-perl. Check the
>>archives, check with him...)
One other thing -- Michael's db3 port was dll-ized. My db2 port (and
yours, I suspect) are static lib only.
>>However, this particular port of db was done during the Cygwin 1.x
>>pre-release days (it *works* with current cygwin's, but I'm no longer
>>sure that it will *compile* with current cygwins. So perhaps your
>>effort is better, since it's more recent.)
> Maybe, it would serve my self-respect to think so, but probably not. The
> issues most likely aren't that severe, but 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?
It could happen, especially if your NT system uses NTFS rather than FAT.
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.
> Well if it is on your site then it is "available", if peeps can find it ...
> to put it none too diplomatically, I sometimes find it hard to navigate /
> find things on the site (it might have to do with the late hours and blurred
> vision that often accompanies such endeavors for me ..). Anyway.
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
> OTOH, from another pov this really seems rather trivial to me (the
> concerns/issues you mention seem not to fit well with this instance I have
> raised, I mean). It wasn't that hard to do and it seems like a special
> case -- enabling something that works with Perl, for modules that are
> long-established and that some other interesting code that's out there,
> depends on. 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"? At some point with Perl extensions the period
> got put on the end of the sentence. It seems to me that abstract philosophy
> regarding Open Source development is interfering with practical
> value-creation here.
> I will be happy to offer my materials on *my* website. If DIY and
> Each-To-Her-Own seems to be the way to go instead of monolithic officiality.
> Many fewer people will have access to it, that way. I have no agenda and no
> ax to grind, I just love Cygwin and would have liked to contribute something
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
"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>
The perl source package contains a limited number of
perl5porters-blessed extensions. Some of these blessed extensions
depend on external libraries. Some of those required librares are part
of the official cygwin distro; the blessed extensions depending on THOSE
libraries are built in the cygwin-official perl binary. However, some
of the required libraries are NOT part of the official cygwin distro;
the blesed extensions depending on the non-official libs are NOT built.
Currently, the non-built blessed extentions include SysV::IPC, DB_File
(possibly others). My belief is, once the required libraries become
part of the official cygwin distribution, then the cygwin-perl
maintainer will build a perl release that builds the (currently omitted)
Note 1: yes, cygwin-perl updates have been slow recently. I have reason
to believe that may change soon.
Note 2: libcygipc (required on cygwin for SysV::IPC) will never be part
of cygwin; therefore, if SysV::IPC is to be built into the official
perl, the work on cygwin-developers toward including IPC functionality
directly into cygwin1.dll (and Egor's daemon) will have to be completed
Now, perl has other extensions that AREN'T distributed as part of the blessed
bundle within the perl source tarball. Those, folks can build easily for
themselves using CPAN, and the "official" cygwin-perl. Strangely, it's the
blessed extensions that MUST be built by the maintainer...there's just no
way around it; sorry, Soren.
Back when I distributed perl from cygutils, I experimented with using
RPM to distribute extensions. However, that kind of subpackaging is
just WAY too difficult without the appropriate infrastructure --
currently we don't have it. We'd need either rpm -- which has been
ported but there are a few issues with using it to install cygwin
packages (*) -- or the current setup would HAVE to support dependencies
which it doesn't, yet. AND, Eric would have to do it -- and I'm not
gonna volunteer him for that.
(*) 1) we've standardized on setup.exe tarballs and /etc/postinstall
structure, not rpm's. 2) To use rpm as a fully-vested format for cygwin
setup, we'd have to change setup to use the rpm database (EVEN for
tarballs) instead of the /etc/setup/*.lst.gz "database", and we'd have
to fully port rpm to NATIVE windows -- you can't use a cygwin program to
install cygwin1.dll itself, without lots of newbie-confusing bootstrap
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.
Help add IPC functionality to cygwin1.dll (but NO peeking at cygipc --
copyright issues). The "regular" extensions can be built using the CPAN
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
More information about the Cygwin