Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: 30 Sep 2004 06:03:29 -0000 Message-ID: <20040930060329.10646.qmail@mail.tsm32.com> To: cygwin AT cygwin DOT com Subject: Solution for: RE: ./configure in any package fails to create Makefile X-IlohaMail-Blah: mark AT pumptheory DOT com X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo In-Reply-To: <20040922234906.14767.qmail@mail.tsm32.com> From: "Mark Aufflick" Bounce-To: "Mark Aufflick" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id i8U6U5KJ023590 Followup: The process is below, the solution is right here: The problem is that config.status will use an environment variable to choose which files to create instead of it's own list (if it exists). The trouble was I had cleared this variable with: export CONFIG_FILES= but to the shell, an empty string is still an existing variable, so when config.status sets the file list as: CONFIG_FILES="${CONFIG_FILE-file list}" it gets set to blank instead of "file list" What I SHOULD have said before ./configure was: unset CONFIG_FILES which removes the variable from existence rather than setting it to blank. Now ./configure creates the Makefiles which run successfully - Praise the Good Lord!! Now THAT was a hard lesson to learn... autoconf really should include warnings when a 'feature' like this is used - it would probably be used intentionally less often than it silently breaks your install. For the curious, here are some of the steps I went through: * unset a bunch of wierc environment variables set by some crazy windows installer and/or sysadmin, including but not limited to: LANG (which was enu) CONFIG_FILES (for oracle.ini - not even installed) * tar unzip the source tree * in the main dir, run ./configure as normal * ./configure creates and runs ./config.status, which creates the required header files but not the Makefiles * I can create the base Makefile with ./config.status --file=Makefile * ergo, I can recursively make all the Makefiles: for f in `find . -name Makefile.in`; do ./config.status --file=`dirname $f`/Makefile; done make then runs, but has linking errors - probably because the LIBDIR's etc. set by ./configure are no longer in the environment. so I tried the --recheck option to config.status which loads data from the config.cache and (frustratingly despite the --no-recursion option) re-runs ./configure multiple times - roughly e to the power of the number of Makefiles (how many times do I have to tell you I'M NOT USING FORTRAN ON ULTRIX?!!) But since it is ./configure that finally spawns ./config.status, my command line options are ignored and the Makefiles are not created. Next I hacked ./configure. Near the end, before the if block that actually runs config.status (look for $SHELL $CONFIG_STATUS), I added: ac_config_status_args= for mfin in `find . -name Makefile.in` do mf=`dirname $mfin`/Makefile ac_config_status_args="$ac_config_status_args --file=$mf" done and deleted the line that clears the args var inside the if block (look for the line: ac_config_status_args= and delete it. I missed this the first time, and so my change had no impact. to manually tell the newly created config.status to make the Makefiles Still - make wouldn't link. This was for librep. When I shifted my attention to imlib, it seemed to have a configure made by an older version of autoconf. It didn't allow the --file option. Then I poked inside config.status, saw where it got it's file-list from, and WHAMMO "Mark Aufflick" wrote: > >./configure completes fine, but creates no Makefile. It creates all the >header files (config.h etc.) though. > >This happens the same with or without cygwin patches applied to the >source. > >In a fit of giving up I installed Window Maker - only to find i needeed >to recompile libtiff with LZW. > >Interestingly, libtiff uses a non-standard configure, and this configures >and makes fine. > >So it is purely a problem with GNU configure... > -- Mark Aufflick e: mark AT pumptheory DOT com w: www.pumptheory.com (business) w: mark.aufflick.com (personal) p: +61 438 700 647 f: +61 2 9436 4737 -- 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/