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/
