Re: should libtool check for the correct version of find?

[Matthew Arnison <mra at cisra dot canon dot com dot au>]

On Sunday 28 September 2003 10:41 pm, Earnie Boyd wrote:
> Matthew Arnison wrote:
> > My suggestion is that libtool should get configure to check for the
> > correct version of find (i.e. Unix find not WINDOWS find) as part of
> > checking the general environment. I feel that configure's job is to
> > check that all the correct tools are in place to do a build, so if
> > libtool is used, then configure/libtool should check which find is
> > being run.
>
> Let's see, I've been involved with Cygwin for about five years and not
> reading the Cygwin FAQ and other documentation before starting is the
> biggest error from Cygwin newbies I've found.  This isn't something
> libtool needs to concern itself with.

I read the documentation.

However, the build was working with a local login, and failing with a 
certain kind of remote login. In addition, other Unix builds (which 
presumably did not depend on find) *were* working remotely.

To diagnose the problem, I had a lengthy build log with several errors in 
it and two main suspects: Cygwin line endings and the environment 
variables. Cygwin also has idiosyncracies (inherited from Windows) with 
switching users in batched jobs and in mounting network drives, which was 
relevant for me as I was trying to get a nightly build working.

If configure had reported on the useless FIND, I would have been able to 
eliminate all the other suspects straight away.

> Then you've not setup Cygwin appropriately for this.  Probably something
> else that's in the FAQ.

Remote batched execution under Cygwin is not something I've found any 
official Cygwin docs for. I am using the default setup. Things work fine 
locally. But with a fairly standard install it seems Cygwin sshd bypasses 
the normal PATH setup when a user runs remote commands via ssh. This 
poorly documented selective sourcing of startup scripts under Unix is 
something that I think could really be improved on by the distributions, 
but that's another story.

> Since, just as yourself, others will fail to read, others will still
> have pains.

I am not suggesting that libtool should bring up the user's web browser and 
point them at the Cygwin FAQ.

I am simply suggesting that if libtool dependson a certain version of find, 
then configure+libtool should check for that version of find, just as it 
checks all the other Unix tools it depends on before attempting to use 
them in a build.

If configure checked for a usable version of find, it would have given me a 
simple error and stopped the build before it started. To my mind that's 
exactly why configure exists: to make it easier to for software to compile 
on all the diverse flavours of Unix by checking carefully everything that 
the software build depends upon.

The best argument I can see against this is that I had remote logins under 
Cygwin setup incorrectly. But think of the case on a Sun machine where a 
Unix build depends on GNU make instead of Solaris make. Remote login might 
switch the path and put the wrong one first, but for this case configure 
would detect the problem immediately and alert the user. It would be 
considered a serious error for the build to be allowed to continue and 
thereby allow Solaris make to spew mysterious errors.

Or think about what would happen if a software build was working fine on 
SGI IRIX, until SGI decided to change the default version of one of the 
build tools in a way that it broke the build. The right thing to do would 
be to add a test in the configure script for any software that depended on 
that build tool.

>From my point of view there is little difference between the above Solaris 
and SGI cases, and what happened to me on Cygwin .

Now I think about it, the libtool response to the Windows FIND was also 
somewhat surprising. When FIND failed with "Parameter format not correct", 
libtool carried on regardless and built a library with most of the object 
files missing. The error that finally stopped the build was when gcc tried 
to link against that library. 

However, I can understand that Windows FIND probably doesn't return the 
normal Unix-like exit codes which libtool can check. In my mind this makes 
an even stronger argument for checking for find in the configure script. 
The sooner a bug is caught, the less havoc it can cause.

Once again, I apologise for not being able to offer a patch at this stage. 
However, I offer this bug report in the hope that it is useful 
nonetheless.

Cheers,
Matthew.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/