From: Dave M. <win...@nt...> - 2006-07-03 21:18:27
|
Hi, I've been trying to build the latest Insight release for mingw and I'm experiencing odd problems during configure of various subdirectories which reports "invalid feature name" configure: configuring in doc configure: running /bin/sh '../../../../../insight-6.5/gdb/doc/configure' --prefix=e:/mingw-insight '--cache-file=.././config.cache' '--build=i686-pc-mingw32' '--host=i686-pc-mingw32' '--target=i686-pc-mingw32' '--prefix=e:/mingw-insight' '--disable-nls' '--enable-gdbtk' '--program-transform-name=s,y,y,' '--srcdir=../../../../insight-6.5/gdb' 'CC=gcc' 'CFLAGS=-g -O2' 'LDFLAGS=' 'build_alias=i686-pc-mingw32' 'host_alias=i686-pc-mingw32' 'target_alias=i686-pc-mingw32' --cache-file=../.././config.cache --srcdir=../../../../../insight-6.5/gdb/doc configure: error: invalid feature name: --disable-nls configure: error: /bin/sh '../../../../../insight-6.5/gdb/doc/configure' failed for doc make[1]: *** [configure-gdb] Error 1 make[1]: Leaving directory `/e/projects/devkitPro/test/build/insight/mingw' make: *** [all] Error 2 I'm using msys 1.0.11, msysDTK-1.0.1, bison-2.1, flex-2.5.4a-1, and texinfo-4.8, the latter 3 from the gnuwin project. The build machine is windows 2000 pro SP4. I've also tried configuring with an absolute path but the only thing that works is not to use the --enable-gdbtk and --disable-nls options I've been using. Hacking the configure in the directories which fail seems to work - I noticed that there was a slightly different check in older configure scripts which worked. Index: sim/configure =================================================================== RCS file: /cvs/src/src/sim/configure,v retrieving revision 1.19 diff -u -r1.19 configure --- sim/configure 17 May 2005 14:11:24 -0000 1.19 +++ sim/configure 8 Dec 2005 20:43:03 -0000 @@ -374,26 +374,26 @@ datadir=$ac_optarg ;; -disable-* | --disable-*) - ac_feature=`expr "x$ac_option" : 'x-*disable-\(.*\)'` + ac_feature=`echo $ac_option|sed -e 's/-*disable-//'` # Reject names that are not valid shell variable names. - expr "x$ac_feature" : ".*[^-_$as_cr_alnum]" >/dev/null && - { echo "$as_me: error: invalid feature name: $ac_feature" >&2 - { (exit 1); exit 1; }; } - ac_feature=`echo $ac_feature | sed 's/-/_/g'` - eval "enable_$ac_feature=no" ;; + if test -n "`echo $ac_feature| sed 's/[-a-zA-Z0-9_]//g'`"; then + { echo "configure: error: $ac_feature: invalid feature name" 1>&2; exit 1; } + fi + ac_feature=`echo $ac_feature| sed 's/-/_/g'` + eval "enable_${ac_feature}=no" ;; -enable-* | --enable-*) - ac_feature=`expr "x$ac_option" : 'x-*enable-\([^=]*\)'` + ac_feature=`echo $ac_option|sed -e 's/-*enable-//' -e 's/=.*//'` # Reject names that are not valid shell variable names. - expr "x$ac_feature" : ".*[^-_$as_cr_alnum]" >/dev/null && - { echo "$as_me: error: invalid feature name: $ac_feature" >&2 - { (exit 1); exit 1; }; } - ac_feature=`echo $ac_feature | sed 's/-/_/g'` - case $ac_option in - *=*) ac_optarg=`echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"`;; + if test -n "`echo $ac_feature| sed 's/[-_a-zA-Z0-9]//g'`"; then + { echo "configure: error: $ac_feature: invalid feature name" 1>&2; exit 1; } + fi + ac_feature=`echo $ac_feature| sed 's/-/_/g'` + case "$ac_option" in + *=*) ;; *) ac_optarg=yes ;; esac - eval "enable_$ac_feature='$ac_optarg'" ;; + eval "enable_${ac_feature}='$ac_optarg'" ;; -exec-prefix | --exec_prefix | --exec-prefix | --exec-prefi \ | --exec-pref | --exec-pre | --exec-pr | --exec-p | --exec- \ Obviously this isn't an acceptable patch since I should be patching configure.ac and regenerating. I've had endless trouble with that approach though. It seems that different versions of autoconf/automake are needed for various packages and I'm not entirely sure how to install multiple versions without them interfering with each other. Is this likely to be a problem with my setup? Has anyone encountered anything similar? Dave |
From: Keith M. <kei...@to...> - 2006-07-04 09:30:59
|
Dave Murphy wrote: > I've been trying to build the latest Insight release for mingw > and I'm experiencing odd problems during configure of various > subdirectories which reports "invalid feature name" > ... This isn't a MinGW problem; it's related to bad configure scripts, supplied by the Insight project, so you need to report it there, and possibly also to aut...@gn..., but FWIW... > configure: running /bin/sh > '../../../../../insight-6.5/gdb/doc/configure' > --prefix=e:/mingw-insight '--cache-file=.././config.cache' > '--build=i686-pc-mingw32' '--host=i686-pc-mingw32' > '--target=i686-pc-mingw32' '--prefix=e:/mingw-insight' '--disable-nls' > '--enable-gdbtk' '--program-transform-name=s,y,y,' > '--srcdir=../../../../insight-6.5/gdb' 'CC=gcc' 'CFLAGS=-g -O2' > 'LDFLAGS=' 'build_alias=i686-pc-mingw32' 'host_alias=i686-pc-mingw32' > 'target_alias=i686-pc-mingw32' --cache-file=../.././config.cache > --srcdir=../../../../../insight-6.5/gdb/doc > configure: error: invalid feature name: --disable-nls This is configure's report of the options it was given, at some subdirectory level in the run. You don't show the actual command you used, so based on pure conjecture... Try omitting the options you don't need -- don't specify *any* of `host', `build' or `target'; when they are all the same, there can be no justifiable reason to specify them. The `program-transform-name' here is also redundant -- it transforms `y' to `y'; a no-op, so why bother? The `CC', `CFLAGS' and `LDFLAGS' specified are autoconf defaults, so just let it default them. Also, note that you have somehow achieved two conflicting `cache-file' settings. You could also try specifying options and assignments in a different order; with autoconf versions prior to 2.59, I've seen this sort of behaviour, and IIRC it *was* dependent on the order the options were parsed -- almost certainly an autoconf bug, but I only ever saw it once with autoconf 2.59, and that was only after I'd applied a local patch. Autoconf 2.60 was released last week, so reporting this bug against earlier versions is unlikely to produce fruit. > I've also tried configuring with an absolute path but the only > thing that works is not to use the --enable-gdbtk and --disable-nls > options I've been using. And which you probably need, for a successful build... > Hacking the configure in the directories which fail seems to > work - I noticed that there was a slightly different check in older > configure scripts which worked. > ... > > -disable-* | --disable-*) > - ac_feature=`expr "x$ac_option" : 'x-*disable-\(.*\)'` > + ac_feature=`echo $ac_option|sed -e 's/-*disable-//'` > # Reject names that are not valid shell variable names. > - expr "x$ac_feature" : ".*[^-_$as_cr_alnum]" >/dev/null && > - { echo "$as_me: error: invalid feature name: $ac_feature" >&2 > - { (exit 1); exit 1; }; } > - ac_feature=`echo $ac_feature | sed 's/-/_/g'` > - eval "enable_$ac_feature=no" ;; > + if test -n "`echo $ac_feature| sed 's/[-a-zA-Z0-9_]//g'`"; then > + { echo "configure: error: $ac_feature: invalid feature name" > 1>&2; exit 1; } > + fi > + ac_feature=`echo $ac_feature| sed 's/-/_/g'` > + eval "enable_${ac_feature}=no" ;; Well, the syntax you've replaced looks pretty much like what I get with autoconf 2.59: | -disable-* | --disable-*) | ac_feature=`expr "x$ac_option" : 'x-*disable-\(.*\)'` | # Reject names that are not valid shell variable names. | expr "x$ac_feature" : ".*[^-_$as_cr_alnum]" >/dev/null && | { echo "$as_me: error: invalid feature name: $ac_feature" >&2 | { (exit 1); exit 1; }; } | ac_feature=`echo $ac_feature | sed 's/-/_/g'` | eval "enable_$ac_feature=no" ;; and I've never had a problem with it. > Obviously this isn't an acceptable patch since I should be patching > configure.ac and regenerating. As you say... But in this case, there isn't any change you can make in configure.ac which will influence this -- what you've changed in configure comes from the boiler plate code generated by AC_INIT. If it continues to fail, with current autoconf, then that is a reportable bug. > It seems that different versions of autoconf/automake are needed for > various packages... Welcome to `autohell'; but note that it isn't autoconf that causes this hell -- it's automake. (And this is the prime reason why I so utterly detest automake; I find autoconf *alone* to be quite useful, but add automake to the mix, and the nightmares begin). (And for those who do like automake, please accept that this is my opinion only. However, I've yet to see a convincing argument that would persuade me to change it). Regards, Keith. |
From: Dave K. <dav...@ar...> - 2006-07-04 09:42:30
|
On 04 July 2006 10:29, Keith MARSHALL wrote: > Welcome to `autohell'; but note that it isn't autoconf that causes this > hell -- it's automake. (And this is the prime reason why I so utterly > detest automake; I find autoconf *alone* to be quite useful, but add > automake to the mix, and the nightmares begin). > > (And for those who do like automake, please accept that this is my > opinion only. However, I've yet to see a convincing argument that > would persuade me to change it). http://www.cygwin.com/ml/cygwin-talk/2005-q2/msg00081.html ;) BTW, didn't someone just transition a bunch of the more obscure subdirectories on /src to more recent auto*? Perhaps this is fallout from that? Dave, are you using the latest'n'greatest autotools versions? cheers, DaveK -- Can't think of a witty .sigline today.... |
From: Keith M. <kei...@to...> - 2006-07-04 10:34:38
|
Dave Korn wrote, quoting me: >> Welcome to `autohell'; but note that it isn't autoconf that causes this >> hell -- it's automake. (And this is the prime reason why I so utterly >> detest automake; I find autoconf *alone* to be quite useful, but add >> automake to the mix, and the nightmares begin). >> >> (And for those who do like automake, please accept that this is my >> opinion only. However, I've yet to see a convincing argument that >> would persuade me to change it). > > http://www.cygwin.com/ml/cygwin-talk/2005-q2/msg00081.html > > ;) And quoting DaveK himself, from that very thread: | " BECAUSE AUTOTOOLS IS A SCREAMING INSANE MESS OF NIGHTMARE GIBBERISH | SPAGHETTI NONSENSE THAT WILL SUCK EVERY LAST DROP OF SANITY OUT OF YOUR | BRAIN WITH A STRAW AND LEAVE YOU REELING, DROOLING AND GIBBERING IN A | CORNER DRESSED IN RAGS AND ROLLING IN YOUR OWN FAECES. " Which certainly would *not* convince me to change my opinion, but rather reinforces it. But I'd still say that the real bugbear is automake, and not so much autoconf. There *is* a perfectly acceptable alternative to automake -- it's called a Makefile, plain and simple; but what is the alternative to autoconf? Sure, autoconf generated scripts are not a picture of elegance. Some developers have said to me that they don't use autoconf, because it is easier to just write a configure script by hand. Oh yeah? And how many of those hand crafted configure scripts actually *work*, on any platform other than the one on which their developers wrote them? I've yet to find EVEN A SINGLE ONE, which originated on *nix, and will run under MSYS. IME, autoconf does a pretty good job of dealing with the portability issues; just don't try to decipher the generated script. Learn to read, and interpret configure.ac and aclocal.m4 instead; understanding of the workings of the generated script will likely follow -- it did for me. Of course, there are many quite horrendous examples of how *not* to write configure.ac out there, (many still bearing the deprecated configure.in name). These aren't the fault of autoconf, but rather are due to poor style, on the part of their respective developers. Regards, Keith. |
From: Ralf W. <Ral...@gm...> - 2006-07-04 10:59:15
|
* Keith MARSHALL wrote on Tue, Jul 04, 2006 at 11:28:46AM CEST: > Dave Murphy wrote: > > I've been trying to build the latest Insight release for mingw > > and I'm experiencing odd problems during configure of various > > subdirectories which reports "invalid feature name" > > ... > > This isn't a MinGW problem; it's related to bad configure scripts, > supplied by the Insight project, so you need to report it there, and > possibly also to aut...@gn..., but FWIW... Yes. Please report this to bug-autoconf, giving ./configure --version ../../../../../insight-6.5/gdb/doc/configure --version and whatever other details you can give. An URL to the tarballs helps, too. Bugs that aren't reported are less likely to be fixed. > > configure: running /bin/sh > > '../../../../../insight-6.5/gdb/doc/configure' > > --prefix=e:/mingw-insight '--cache-file=.././config.cache' > > '--build=i686-pc-mingw32' '--host=i686-pc-mingw32' > > '--target=i686-pc-mingw32' '--prefix=e:/mingw-insight' '--disable-nls' > > '--enable-gdbtk' '--program-transform-name=s,y,y,' > > '--srcdir=../../../../insight-6.5/gdb' 'CC=gcc' 'CFLAGS=-g -O2' > > 'LDFLAGS=' 'build_alias=i686-pc-mingw32' 'host_alias=i686-pc-mingw32' > > 'target_alias=i686-pc-mingw32' --cache-file=../.././config.cache > > --srcdir=../../../../../insight-6.5/gdb/doc > > configure: error: invalid feature name: --disable-nls > Try omitting the options you don't need -- don't specify *any* of > `host', `build' or `target'; when they are all the same, there can be > no justifiable reason to specify them. The `program-transform-name' > here is also redundant -- it transforms `y' to `y'; a no-op, so why > bother? The `CC', `CFLAGS' and `LDFLAGS' specified are autoconf > defaults, so just let it default them. Also, note that you have > somehow achieved two conflicting `cache-file' settings. Some of those could be generated by the toplevel configure script automatically. AFAIK the duplicate cache-file has been fixed since in Autoconf. > You could also try specifying options and assignments in a different > order; with autoconf versions prior to 2.59, I've seen this sort of > behaviour, and IIRC it *was* dependent on the order the options were > parsed -- almost certainly an autoconf bug, but I only ever saw it > once with autoconf 2.59, and that was only after I'd applied a local > patch. Again, this can only be fixed when reported. > Autoconf 2.60 was released last week, so reporting this > bug against earlier versions is unlikely to produce fruit. Wrong. I (and others) do look at bug reports for older versions, at least to verify whether they may still be present in the current version. Keith, did we ever discourage you with this in any way? (I think not, rather on the contrary.) Encouraging users to stick with the latest released version is of course usually a good advice, and sometimes simply necessary for a maintainer to keep the workload manageable. > Well, the syntax you've replaced looks pretty much like what I get > with autoconf 2.59: *snip* > and I've never had a problem with it. Underlying this may be a problem with the MSYS shell. I may try to reproduce it when I have time; giving an URL for the package you tried to compile would help greatly (and steps how to reproduce it). I'll not comment on the bashing done towards autotools. Let's just say that being helpful encourages other to be helpful as well. Cheers, Ralf |
From: Dave K. <dav...@ar...> - 2006-07-04 11:10:43
|
On 04 July 2006 11:59, Ralf Wildenhues wrote: > I'll not comment on the bashing done towards autotools. It wasn't my intention to start a debate on autotools, that was a throwaway line; the real *point* in my post was to ask if this might be related to the recent auto* upgrade of /src. cheers, DaveK -- Can't think of a witty .sigline today.... |
From: Keith M. <kei...@to...> - 2006-07-04 12:47:34
|
Ralf Wildenhues wrote, quoting me: >> You could also try specifying options and assignments in a different >> order; with autoconf versions prior to 2.59, I've seen this sort of >> behaviour, and IIRC it *was* dependent on the order the options were >> parsed -- almost certainly an autoconf bug, but I only ever saw it >> once with autoconf 2.59, and that was only after I'd applied a local >> patch. > > Again, this can only be fixed when reported. The local patch I applied was to make AC_INIT and AC_PREFIX_DEFAULT expand MSYS_AC_CANONICAL_PATH, when assigning ac_default_prefix. With that in place, I saw erratic behaviour, with certain combinations of valid command line options and assignments; some combinations would throw an `invalid feature name' exception, for some ordering of the options and assignments, but the same combination in a different order would execute successfully. I didn't report it, because the problem vanished, if I reverted my patch, by restoring a clean autoconf 2.59 installation; (what would be the point in me reporting a bug, which even I cannot reproduce, when I'm using the codebase you would be testing against?) >> Autoconf 2.60 was released last week, so reporting this >> bug against earlier versions is unlikely to produce fruit. > > Wrong. I (and others) do look at bug reports for older versions, at > least to verify whether they may still be present in the current > version. Keith, did we ever discourage you with this in any way? Absolutely not. But you misunderstand me; I wasn't suggesting that the bug should not be reported, since it might still affect current autoconf -- indeed, I said later, in that same post: >> But in this case, there isn't any change you can make in configure.ac >> which will influence this -- what you've changed in configure comes >> from the boiler plate code generated by AC_INIT. If it continues to >> fail, with current autoconf, then that is a reportable bug. What I meant was that, a bug fixed in current autoconf won't fix scripts generated by developers who continue to use the older (possibly buggy) versions. > Encouraging users to stick with the latest released version is of > course usually a good advice, ... Exactly. That's the point I was trying to make! > Underlying this may be a problem with the MSYS shell. I may try to > reproduce it when I have time; ... That's always a possibility. I doubt very much if I've kept the stuff I was playing with, when I noticed the problem -- I just assumed, at the time, that I'd broken it with my local hacking, and discarded it. If I can ever reproduce it again, I'll be sure to let you know. > I'll not comment on the bashing done towards autotools. Let's just > say that being helpful encourages other to be helpful as well. Oh, I wasn't bashing autotools. Yes, I have a negative opinion of automake -- we've discussed that before, and you've never been able to convince me of its value. But I do appreciate that there are others who think it is the greatest thing since sliced bread, and they too are entitled to that opinion; they may continue to use it, to their hearts' content, with my blessing, but I don't want it in any of *my* projects. OTOH, I *do* think autoconf is extremely valuable, and was trying to be helpful, on the basis of my own (positive) experience with it. Regards, Keith. |
From: Dave M. <win...@nt...> - 2006-07-05 17:23:19
|
Keith MARSHALL wrote: > This is configure's report of the options it was given, at some > subdirectory level in the run. You don't show the actual command > you used, so based on pure conjecture... > > Try omitting the options you don't need -- don't specify *any* of > `host', `build' or `target'; when they are all the same, there can be > no justifiable reason to specify them. The `program-transform-name' > here is also redundant -- it transforms `y' to `y'; a no-op, so why > bother? The `CC', `CFLAGS' and `LDFLAGS' specified are autoconf > defaults, so just let it default them. Also, note that you have > somehow achieved two conflicting `cache-file' settings. > > Most of the options shown there were generated from the top level configure script, the only options I specified during configure were --prefix --disable-nls and --enable-gdbtk. Your last point is probably part of my problem and very well spotted that man. I suspect that may be the crux of the matter here. In order to get Insight to build with msy/mingw I need to apply this patch http://sources.redhat.com/ml/insight/2004-q2/msg00032.html Since regenerating configure with my installed autoconf 2.59 results in a number of problems I haven't been able to figure out fully I had the bright idea of patching configure manually which appears to work but I guess that might be the cause of the conflicting cache-file settings. I should really report this on the Insight mailing list but thus far I've had very short shrift over there about building Insight with msys/mingw - "not a supported platform" and similar unhelpful responses. The frustrating thing is that I now have a fairly minimal patch set which will make it a supported platform and the resulting Insight appears to work quite well. This configure issue is the last thing I need to sort out. Since the configure.in used by Insight appears to be the toplevel shared by binutils, gcc et al I suspect I won't get too far attempting to submit a patch to upgrade it for autoconf 2.59 either.Is there any way to use multiple versions of autoconf on an msys/mingw setup and run the required one as needed? In this case I believe I need 2.13 in order to regenerate configure.in properly. >> I've also tried configuring with an absolute path but the only >> thing that works is not to use the --enable-gdbtk and --disable-nls >> options I've been using. >> > > And which you probably need, for a successful build.. With the manually patched configure it appears that the build is successful without those options. I'm not 100% certain that --disable-nls is not required as I ended up removing libiconv from my mingw setup due to problems building a cross gcc without it depending on libiconv-2.dll regardless of that option but that's another story. Dave |
From: Brian D. <br...@de...> - 2006-07-05 17:37:33
|
Dave Murphy wrote: > Since the configure.in used by Insight appears to be the toplevel shared > by binutils, gcc et al I suspect I won't get too far attempting to > submit a patch to upgrade it for autoconf 2.59 either.Is there any way > to use multiple versions of autoconf on an msys/mingw setup and run the > required one as needed? In this case I believe I need 2.13 in order to > regenerate configure.in properly. Yes, this is complicated by the fact that the sourware 'src' tree (of which insight is an occupant) contains a mix of autoconf versions, and you have to regenerate each dir using the correct version. So yes, regenerating the toplevel configure with 2.59 will almost certainly cause strange breakage. The src repo is slowly upgrading piecewise to 2.5x, but as this is a slow process that touches dozens of independant open source projects it will take some time. Regarding multiple installed versions of autoconf, you could probably try installing each into their own completely separate prefixes, and then setting the right env. variables when you run autoconf. Or you could use Cygwin and its autoconf packages which include all the wrapper script-fu necessary for this to work transparently. Brian |
From: Earnie B. <ea...@us...> - 2006-07-05 17:53:24
|
Quoting Dave Murphy <win...@nt...>: > > Since the configure.in used by Insight appears to be the toplevel shared > by binutils, gcc et al I suspect I won't get too far attempting to > submit a patch to upgrade it for autoconf 2.59 either.Is there any way > to use multiple versions of autoconf on an msys/mingw setup and run the > required one as needed? In this case I believe I need 2.13 in order to > regenerate configure.in properly. > There is another troublesome issue with sourceware toplevel configure, it isn't autoconf produced and infact executing autoconf will destroy the configure script to meaningless garbage. The configure.in file is a means to recover from the incidental autoconf execution at the top level; i.e.: cp configure.in configure. This top level configure script came from Cygnus well before autoconf was popularized. There is even a cygnus autoconf style to help with that conversion but I don't know how often it is used. Earnie Boyd http://shop.siebunlimited.com |
From: Dave M. <win...@nt...> - 2006-07-05 21:01:11
|
Brian Dessent wrote: > Regarding multiple installed versions of autoconf, you could probably > try installing each into their own completely separate prefixes, and > then setting the right env. variables when you run autoconf. Or you > could use Cygwin and its autoconf packages which include all the wrapper > script-fu necessary for this to work transparently I'd really rather not install cygwin if at all possible, are these autoconf packages something which could be handled under msys and, if so, where would I get some information on the necessary script-fu. Dave |
From: Earnie B. <ea...@us...> - 2006-07-06 01:17:55
|
Quoting Dave Murphy <win...@nt...>: > Brian Dessent wrote: >> Regarding multiple installed versions of autoconf, you could probably >> try installing each into their own completely separate prefixes, and >> then setting the right env. variables when you run autoconf. Or you >> could use Cygwin and its autoconf packages which include all the wrapper >> script-fu necessary for this to work transparently > I'd really rather not install cygwin if at all possible, are these > autoconf packages something which could be handled under msys and, if > so, where would I get some information on the necessary script-fu. > I think all you would need would be the autoconf package from cygwin/resources that controls he multiple versions of autoconf. IIRC, it is a script that executes choosing the appropriate autoconf version directory. It does assume that you have each differing version in a set path but you should be able to determine where that should be from the script. Earnie Boyd http://shop.siebunlimited.com |
From: Earnie B. <ea...@us...> - 2006-07-04 15:40:46
|
Quoting Dave Murphy <win...@nt...>: > Hi, > > I've been trying to build the latest Insight release for mingw and I'm > experiencing odd problems during configure of various subdirectories > which reports "invalid feature name" > > configure: configuring in doc > configure: running /bin/sh > '../../../../../insight-6.5/gdb/doc/configure' > --prefix=e:/mingw-insight '--cache-file=.././config.cache' > '--build=i686-pc-mingw32' '--host=i686-pc-mingw32' > '--target=i686-pc-mingw32' '--prefix=e:/mingw-insight' '--disable-nls' > '--enable-gdbtk' '--program-transform-name=s,y,y,' > '--srcdir=../../../../insight-6.5/gdb' 'CC=gcc' 'CFLAGS=-g -O2' > 'LDFLAGS=' 'build_alias=i686-pc-mingw32' 'host_alias=i686-pc-mingw32' > 'target_alias=i686-pc-mingw32' --cache-file=../.././config.cache > --srcdir=../../../../../insight-6.5/gdb/doc > configure: error: invalid feature name: --disable-nls > configure: error: /bin/sh '../../../../../insight-6.5/gdb/doc/configure' > failed for doc Highlighting the error; this error indicates that the configure.ac located in gdb/doc doesn't support NLS in the first place. IIRC, their is a gettextize or some such executable that supplies the appropriate m4 code to autoconf to add the necessary bits for --disable-nls to work. So the package builder has work to do in supplying the appropriate additional pieces for the subsequent configure scripts. > > Is this likely to be a problem with my setup? Has anyone encountered > anything similar? > No, it is not your setup. It is mearly the fact that the gdb/doc/configure script doesn't support the --disable-nls switch. OT: Autoconf has a goal to provide a method to create a Makefile and config.h file with C style preprocessor macros set to indicate that a system or runtime feature exists or doesn't exist. It requires, some m4 scripts, an configure.ac and a Makefile.in to create the final configure script. The end user should never be required to have autoconf installed to execute the configure script. Automake has a goal to provide a method to create the Makefile.in needed by autoconf. It uses an input file Makefile.am that contains a set of variables whose names present target features in the Makefile.in and whose values lists the dependencies of the target. Not required and adds to the complexity because you have to learn the variable naming scheme for automake. Libtool has a goal to provide a common means to control library creation and use. It is an addition to autoconf and gives a normalized way of controlling library creation whether static or dynamic by providing autoconf the necessary m4 code to generate a script during the configure process. It needs to modify the make normalized variables such as CC and automake is a good method for doing that. Earnie Boyd http://shop.siebunlimited.com |
From: Keith M. <kei...@to...> - 2006-07-04 16:03:46
|
Earnie Boyd wrote: [concerning an apparently autoconf related bug] > No, it is not your setup. It is mearly the fact that the > gdb/doc/configure script doesn't support the --disable-nls switch. No, that isn't correct. Any autoconf generated configure script should accept `--disable-anything', and silently ignore it, if the associated `anything' feature isn't supported. The error message Dave reported comes from the AC_INIT code itself; there is no dependency on any further m4 code. This is simply a buggy configure script. Ralf Wildenhues is aware of the problem, but needs a bug report from Dave to progress it; it may be a bug in some old autoconf version, which is now fixed; OTOH it may still be dormant in the latest version. Until we can reliably reproduce the problem, it's impossible to chase down. Regards, Keith. |