Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <000601c0fdad$3957d180$36ab313f@sigmund>
Reply-To: "Soren Andersen" <soren AT wonderstorm DOT com>
From: "Soren Andersen" <soren AT wonderstorm DOT com>
To: <cygwin AT cygwin DOT com>
References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20010624204747 DOT 024b8828 AT pop3 DOT cris DOT com>
Subject: Re: cp error -- oh the great sanity of *nix tools?!?
Date: Mon, 25 Jun 2001 15:29:45 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The estimable Randall R Schulz <rrschulz AT cris DOT com> responded Re: cp error --
oh the great sanity of *nix tools?!?


> Perhaps those two files _were_ the same. Namely, if make's current
> directory was /usr/sbin at time the cp commands were invoked.

I was not. I made sure of that in the Makefile script,  even had it print
out where it was to make sure.

> I don't believe cp reports that the source and destination files are the
> same unless they are. Surely you would rather it do this than open the
> destination with the create and truncate options and then copy the source
> (now empty) to it?
> Same as on any Unix, Linux, BSD, FreeBSD, AIX, HPUX or other Unix
work-alike.

Ahh, as it turns out, NOT. And therein lies this GOTCHA. Read on.

And  Mac ("Michael A. Chase" <mchase AT ix DOT netcom DOT com>)  also wrote in his own
reply:

>Because Cygwin mounts allow the same directory to be reachable by
>different routes, it is not always obvious to the user whether two
>directories or files are the same. I guess the same could be true with
>symbolic links in normal UNIXs.

I guess, if I think about it for more than 1.8 sec I begin to get a headache
.. :-).

>Please confirm what directory make was working in when it tried to
>copy those files. The output from 'mount' is also needed to see if
>that directory and /usr/sbin/ are really the same directory.

They are not.

OK, all those who were in nearly intolerable suspense waiting for me to get
to the answer:

It's Cygwin, AND it' s `cp'. Yep. A most unfortunate interaction. To start
with, Cygwin's gcc automatically "maps" an output executable file with an
`.exe' extension filename. That's SO helpful, yes, and might usually be A
Very Good Thing. But NOT this time.

The files I was trying to copy SIMPLY DIDN'T EXIST in the directory I built
in. Because the names came from the Makefile code, but the actual files on
disk were $(PROGS).exe, that is ... each one has .exe caboosed to it ...
because of this I had to bang my head against the proverbial wall until I
saw exactly what was in the build directory.

It IS still  `cp' s fault, too. The message is cp's utterly unhelpful and
misleading way of telling me that the source files named as command
parameters don't exist -- and what the heck is THAT? That's a bona-fide BUG
if ever I was bitten by one. I am really astonished at this, in GNU
software.

                          * * * * * * * * * * * * * * * * * * * *

I have a fixed Makefile.IN prepared now for this package (Berkeley DB
2.7.7). This software's author (SleepyCat) will I am sure *never* be
interested in fixing his Makefile/configure setup for Cygwin, because it is
an old release. It is the highest-numbered 2.x release. I chose it because
the documentation that comes with Perl5.6.1/Cygwin says to do so (to use a
more recent bdb2.x that has the bdb1.xx-compatibility option, to not break
older Perl module code). So although it is an old package, it is IMHO *not*
irrelevent to Cygwin users (at least to those who might want to compile
their own Perl from source), since it is a Perl dependency. So, who is the
Maintainer of this sort of thing (Cygwin-Perl)? Can someone cite an
individual to whom I could forward my fixed Makefile.IN? So that it can be
incorporated into a package to add to the existing Cygwin-ported libraries?
I had to fix some of the code, too (all only macro stuff of course).

   Regards,
     Soren Andersen
   Cygwin Enthusiast

> At 19:58 2001-06-24, *I* wrote:
> >Dogma: GNU/*nix  programming is *always* so much better than what Redmond
> >can produce. Yeah, like.
> >
> >I am running a Makefile installation (`make install') and I keep getting
> >this error (the package is BerkeleyDB, this is irrelevent):
> >
> >
> >./db_checkpoint -> /usr/sbin/db_checkpoint
> >/usr/bin/cp: `./db_checkpoint' and `/usr/sbin/db_checkpoint' are the same
> >file
> >./db_deadlock -> /usr/sbin/db_deadlock
> >/usr/bin/cp: `./db_deadlock' and `/usr/sbin/db_deadlock' are the same
file
> >./db_dump -> /usr/sbin/db_dump
> >/usr/bin/cp: `./db_dump' and `/usr/sbin/db_dump' are the same file
> >./db_load -> /usr/sbin/db_load
> >/usr/bin/cp: `./db_load' and `/usr/sbin/db_load' are the same file
> >./db_printlog -> /usr/sbin/db_printlog
> >/usr/bin/cp: `./db_printlog' and `/usr/sbin/db_printlog' are the same
file
> >./db_recover -> /usr/sbin/db_recover
> >/usr/bin/cp: `./db_recover' and `/usr/sbin/db_recover' are the same file
> >./db_stat -> /usr/sbin/db_stat
> >/usr/bin/cp: `./db_stat' and `/usr/sbin/db_stat' are the same file
> >make: *** [install] Error 1
> >
> >You know, the hacker who wrote `cp' to give this error wording needs to
be
> >put up against a wall and *shot*.
> >
> >What does this mean? I am sure that this is "one of those things" that
> >everybody but me and two guys in Duluth seem to know.
> >
> >REALLY F*%$!)($! IRRITATED,
> >    soren andersen
> >
> >
> >
> >--
> >Want to unsubscribe from this list?
> >Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple