[Mingw-notify] [ mingw-Bugs-1226400 ] Problem rebuilding 'findutils' and 'fileutils'.

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1226400, was opened at 2005-06-23 13:20
Message generated for change (Comment added) made by mtew
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1226400&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Max TenEyck Woodbury (mtew)
Assigned to: Earnie Boyd (earnie)
Summary: Problem rebuilding 'findutils' and 'fileutils'.

Initial Comment:
If you build the 'findutils' in the MSYS source package
under a recent version of MSYS, the resulting
'find.exe' exits without performing any useful function.

This is apparently due to an assumption in the 'find'
code that if 'fchdir' works, you will be able to 
'open( <dir>, O_READONLY)'
which is not the case under windows.

A usable work-around it to force the configure script
to NOT
use 'fchdir' by presetting the cache variable
ac_cv_func_fchdir to 'no'.

Note that this is a build bug, not a bug with the
current version of 'find.exe', nor is it a MSys
run-time bug.  It may really be a autoconf problem or a
findutil problem, but it is also 'our' problem since
some people may use our system to rebuild 'find' from
sources we provide and expect the resulting executable
to be usable.

----------------------------------------------------------------------

>Comment By: Max TenEyck Woodbury (mtew)
Date: 2005-06-30 09:57

Message:
Logged In: YES 
user_id=735003

Here is a patch that I believe corrects the problem.  Change
log:

2005-06-30  Max T. Woodbury <mt...@us...>

        * fhandler.cc (fhandler_disk_file::open): Fake
successful open on directories for !iswinnt.

----------------------------------------------------------------------

Comment By: Max TenEyck Woodbury (mtew)
Date: 2005-06-26 14:30

Message:
Logged In: YES 
user_id=735003

The following link seems to be relavant:

http://homepages.nildram.co.uk/~phekda/richdawe/djgpp/2.04/fchdir.txt

----------------------------------------------------------------------

Comment By: Max TenEyck Woodbury (mtew)
Date: 2005-06-26 14:21

Message:
Logged In: YES 
user_id=735003

There is a similar problem with 'fileutils' that is also
solved by turing off use of 'fchdir'.

Earnie: Could you please post the 'config.log' from your
build of 'findutils'. 

I'm going to look at the POSIX definition of 'fchdir' if
there is one.

Oh, and thanks for the pointer to 'nm'.  I knew there had to
be a tool like that someplace, had found 'objdump', but this
is so much more concise.  I'm still learning some of this,
so thanks again.

----------------------------------------------------------------------

Comment By: Max TenEyck Woodbury (mtew)
Date: 2005-06-25 04:16

Message:
Logged In: YES 
user_id=735003

Actually we already know that.  It breaks for me because
whoever wrote line 248 of find.c made a mistake.  The real
question is why did you not see a working 'fchdir' while I
did.  As you'll see there are no messages in config.log from
the build that produced the unusable executable.  If you
would post a copy of the log from your build, we can compare
the two.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2005-06-24 20:13

Message:
Logged In: YES 
user_id=15438

actually ``nm /bin/find.exe'' is enough to show no fchdir.

Why does the build break for you and not me?

----------------------------------------------------------------------

Comment By: Max TenEyck Woodbury (mtew)
Date: 2005-06-24 18:00

Message:
Logged In: YES 
user_id=735003

Yes, it works, but I think I have reasonable evidence that
it was built without 'fchdir'.  The conditional block
mentioned before:

#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

will compile different strings depending on which branch is
included.  The failing executables contain "cannot open
current directory" and do not contain "cannot get current
directory", while the ones that work (that is the ones
distributed and the ones I built using the 'work-around')
contain "cannot get current directory" and do not contain
"cannot open current directory".

It might be a NT vs 98 problem.  It could also be that you
have fixed a run-time or header problem since you configured
find.  If you have the 'config.log' from when you configured
find, it will tell why it did not use 'fchdir'.  Since the
configure I did found no problems with 'fchdir', the log I
have does not contain a detailed report on 'fchdir'.

A perminant solution would be to change the test used by
configure to test for both 'fchdir' and the ability to open
a directory, either as a local .m4 macro or in the global
autoconf set.  Before doing that, we
should check to see if there is a more recent 'findutils'
and if there is, if it has the same problem and finally see
if the 'findutils' maintainer wants to fix the problem or if
we have to.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2005-06-24 13:28

Message:
Logged In: YES 
user_id=15438

Does the distributed find executable work for you?  I did
nothing special to turn off HAVE_FCHDIR when I configured
the find command.  I'm guessing that this has to do with
MSYS and NTFS vs FAT32.

----------------------------------------------------------------------

Comment By: Max TenEyck Woodbury (mtew)
Date: 2005-06-24 08:03

Message:
Logged In: YES 
user_id=735003

'fchdir' works fine.  It's an 'open' that fails.  The 'open'
fails because it is a directory that is being opened, and
you CAN'T DO THAT in windows.  (There is a seperate series
of functions for directores.)  The problem is in
msys/package/findutils/4.1/find/find.c:245.  Whoever wrote
that assumed that if 'fchdir' worked then you could 'open' a
directory.  The work-around is to make the conditional
compilation block at 240-248 use it's main clause which does
not use 'open' instead of its #else clause which does.  That
is HAVE_FCHDIR should be undefined.  'configure' will
generate a config.h file with that property if
ac_cv_func_fchdir ends up with a value of 'no'.  Since
fchdir WORKS on recent MSYS versions, the only easy way to
do that is to establish that condition (that is
ac_cv_func_fchdir='no') before running configure or have
configure read that value from its config.cache file.

The test case is to build 'find.exe' on a MSYS system where
'fchdir' works and observe that find.exe is useless or not.
 (I've tried this under both 1.0.10 and 1.0.11 snapshot. 
Both fail without the 'work-around'.)

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2005-06-23 18:35

Message:
Logged In: YES 
user_id=15438

If fchdir doesn't work then it is a bug in MSYS.  Forcing
the build to not use fchdir is not the perminent solution
but a workaround for the bug.

Test case please.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1226400&group_id=2435

[Mingw-notify] [ mingw-Bugs-1226400 ] Problem rebuilding 'findutils' and 'fileutils'.

A native Windows port of the GNU Compiler Collection (GCC)

[Mingw-notify] [ mingw-Bugs-1226400 ] Problem rebuilding 'findutils' and 'fileutils'.