This is the mail archive of the
mailing list for the Cygwin project.
Re: should libtool check for the correct version of find?
- From: Matthew Arnison <mra at cisra dot canon dot com dot au>
- To: Earnie Boyd <earnie at users dot sourceforge dot net>
- Cc: libtool at gnu dot org, cwilson at ece dot gatech dot edu, cygwin at cygwin dot com
- Date: Mon, 29 Sep 2003 08:14:57 +1000
- Subject: Re: should libtool check for the correct version of find?
- References: <email@example.com> <3F76D700.firstname.lastname@example.org>
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html