|
From: Earnie B. <ea...@us...> - 2005-06-23 07:49:48
|
On 4:55:57 am 2005-06-23 "Max T. Woodbury" <ma...@mt...> wrote:
> Earnie Boyd wrote:
> >
> > On 2:58:45 am 2005-06-23 "Max T. Woodbury" <ma...@mt...>
> > > wrote: This is a follow-up on the problem with 'find'. As noted
> > > the resulting program was not usable. I found a way around the
> > > problem. 'configure' has to be told not to use 'fchdir'. If you
> > > are doing the configure by hand, include ac_cv_func_fchdir='no'
> > > at the beginning of the line where you invoke 'configure'. With
> > > the driver script, use the new details file attached.
> >
> > You must not be doing something correctly. I've never had to do
> that!
>
> Follow up from my previous reply...
>
> I was trying to think of a way to tell which way the 'official' find
> was built - with or without 'fchdir' and I realized the snippet I
> included could be the basis of that test...
>
> #ifndef HAVE_FCHDIR
> starting_dir = xgetcwd ();
> if (starting_dir == NULL)
> error (1, errno, "cannot get current directory");
> #else
> starting_desc = open (".", O_RDONLY);
> if (starting_desc < 0)
> error (1, errno, "cannot open current directory");
> #endif
>
> The strings in the error messages are different and long enough to
> make a good match test. I used 'grep' (twice) to look for both
> strings in your find.exe. It only found a match on the 'get' form,
> not the 'open' form, which is a good argument that HAVE_FCHDIR was
> not defined when you built it. Why it got defined on my system and
> not your's is a good question but the right answer is still to not
> have it defined. Forcing a 'no' into the cache for that question
> is the way to do that.
>
Please open a bug report with a working sample of this code. It would be
MSYS that needs fixed here. You'll need to include the xgetcwd function in
the test.
> It's 1:00 AM here. I think I'll go to bed early...
>
I worked from 11:00PM Saturday to 10:00 AM Sunday if it helps you any. :)
Earnie
|