From: Eli Z. <el...@gn...> - 2013-02-19 17:46:50
|
I needed Autoconf 2.69, but the initial attempt to build it failed. Digging inside the failure, I found that it happens because the configure script rejects the MSYS m4 I have installed, claiming that it has some obscure bug. That is the latest MSYS m4 available from the MinGW site, version 1.4.14; Autoconf 2.69 wants version 1.4.16 or later. I have a MinGW compiled m4 v1.4.16, which the configure script tried to use instead, but using it in the build process causes the failure, most probably due to some issue with end-of-line format mismatch. (I fixed that by hacking the configure script to skip the offending test, so that MSYS m4 could be used.) Is it possible to upload an MSYS build of a newer m4, please? TIA |
From: Earnie B. <ea...@us...> - 2013-02-19 18:34:44
|
On Tue, Feb 19, 2013 at 12:46 PM, Eli Zaretskii wrote: > > Is it possible to upload an MSYS build of a newer m4, please? > There is a ticket[1] open assigned to Chuck Wilson just for this. However, Chuck has been silent for some time now. In your native build of m4 does adding the /mingw/lib/binmode.o to the link help with the \r\n issue? [1] https://sourceforge.net/p/mingw/bugs/1920/ -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2013-02-19 18:38:51
|
> Date: Tue, 19 Feb 2013 13:34:37 -0500 > From: Earnie Boyd <ea...@us...> > > On Tue, Feb 19, 2013 at 12:46 PM, Eli Zaretskii wrote: > > > > Is it possible to upload an MSYS build of a newer m4, please? > > > > There is a ticket[1] open assigned to Chuck Wilson just for this. > However, Chuck has been silent for some time now. Maybe someone else could step forward. > In your native build of m4 does adding the /mingw/lib/binmode.o to the > link help with the \r\n issue? Maybe, I should try that some day. But using MinGW executables when running sophisticated shell scripts in MSYS Bash is not generally recommended, anyway... |
From: Alexpux <al...@gm...> - 2013-02-19 20:20:38
|
Look at msys package at http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages. We have there m4-1.4.16 and latest automake/autoconf. Also libtool-2.4.2. 19.02.2013, в 22:38, Eli Zaretskii <el...@gn...> написал(а): >> Date: Tue, 19 Feb 2013 13:34:37 -0500 >> From: Earnie Boyd <ea...@us...> >> >> On Tue, Feb 19, 2013 at 12:46 PM, Eli Zaretskii wrote: >>> >>> Is it possible to upload an MSYS build of a newer m4, please? >>> >> >> There is a ticket[1] open assigned to Chuck Wilson just for this. >> However, Chuck has been silent for some time now. > > Maybe someone else could step forward. > >> In your native build of m4 does adding the /mingw/lib/binmode.o to the >> link help with the \r\n issue? > > Maybe, I should try that some day. > > But using MinGW executables when running sophisticated shell scripts > in MSYS Bash is not generally recommended, anyway... > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
From: waterlan <wat...@xs...> - 2013-02-20 11:41:19
|
Eli Zaretskii schreef op 2013-02-19 19:38: >> Date: Tue, 19 Feb 2013 13:34:37 -0500 >> From: Earnie Boyd <ea...@us...> >> >> On Tue, Feb 19, 2013 at 12:46 PM, Eli Zaretskii wrote: >>> >>> Is it possible to upload an MSYS build of a newer m4, please? >>> >> >> There is a ticket[1] open assigned to Chuck Wilson just for this. >> However, Chuck has been silent for some time now. > > Maybe someone else could step forward. > For me this usually boiled down to that I had to do it myself. So if you have some spare time... regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Eli Z. <el...@gn...> - 2013-02-19 21:18:02
|
> From: Alexpux <al...@gm...> > Date: Wed, 20 Feb 2013 00:20:25 +0400 > > Look at msys package at > http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages. We > have there m4-1.4.16 Thanks! > and latest automake/autoconf. Also libtool-2.4.2. Well, these are not really MSYS-specific, they are just scripts. Building and installing them is a no-brainer, really. |
From: Eli Z. <el...@gn...> - 2013-02-20 18:41:29
|
> Date: Wed, 20 Feb 2013 12:41:08 +0100 > From: waterlan <wat...@xs...> > > >> There is a ticket[1] open assigned to Chuck Wilson just for this. > >> However, Chuck has been silent for some time now. > > > > Maybe someone else could step forward. > > > > For me this usually boiled down to that I had to do it myself. > So if you have some spare time... Not enough to become involved with MSYS development environment, sorry. |
From: Eli Z. <el...@gn...> - 2013-02-20 19:04:19
|
> From: Alexpux <al...@gm...> > Date: Wed, 20 Feb 2013 00:20:25 +0400 > > Look at msys package at http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages. We have there m4-1.4.16 and latest automake/autoconf. Also libtool-2.4.2. Thanks, I used that. Just a note: perhaps you shouldn't yet switch to version 0.4 of 7z archives, as it is not yet widely supported, except by the latest versions of 7-zip. (E.g., the latest version of bsdtar, released 2 weeks ago, still says "Corrupted archive".) Thanks again for providing these resources. |
From: Erwin W. <wat...@xs...> - 2013-02-20 20:52:34
|
Op 20-2-2013 19:41, Eli Zaretskii schreef: >> Date: Wed, 20 Feb 2013 12:41:08 +0100 >> From: waterlan <wat...@xs...> >> >>>> There is a ticket[1] open assigned to Chuck Wilson just for this. >>>> However, Chuck has been silent for some time now. >>> Maybe someone else could step forward. >>> >> For me this usually boiled down to that I had to do it myself. >> So if you have some spare time... > Not enough to become involved with MSYS development environment, > sorry. I will give it a try. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Erwin W. <wat...@xs...> - 2013-02-20 22:06:58
|
Op 20-2-2013 21:52, Erwin Waterlander schreef: > Op 20-2-2013 19:41, Eli Zaretskii schreef: >>> Date: Wed, 20 Feb 2013 12:41:08 +0100 >>> From: waterlan <wat...@xs...> >>> >>>>> There is a ticket[1] open assigned to Chuck Wilson just for this. >>>>> However, Chuck has been silent for some time now. >>>> Maybe someone else could step forward. >>>> >>> For me this usually boiled down to that I had to do it myself. >>> So if you have some spare time... >> Not enough to become involved with MSYS development environment, >> sorry. > I will give it a try. > > regards, > Hi, I have tried it, but I have a problem during the configure step. Configure hangs forever during this step: checking whether strstr works in linear time... To reproduce: 1. Download the files from http://waterlan.home.xs4all.nl/msys/m4/ in a new folder. 2. Make sure your msys packages are up to date, as mentioned in m4.README. 3. Start an msys special shell with this command: msys.bat MSYS 4. Start package creation in msys shell with this command: mgwport m4-1.4.16-1.msysport almostall If somebody knows a fix, please let me know. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Alexpux <al...@gm...> - 2013-02-21 02:22:46
|
I have successfully builded m4-1.4.16. If you need I can upload source package with script and patch that works. Regards, Alexey. 21.02.2013, в 2:06, Erwin Waterlander <wat...@xs...> написал(а): > Op 20-2-2013 21:52, Erwin Waterlander schreef: >> Op 20-2-2013 19:41, Eli Zaretskii schreef: >>>> Date: Wed, 20 Feb 2013 12:41:08 +0100 >>>> From: waterlan <wat...@xs...> >>>> >>>>>> There is a ticket[1] open assigned to Chuck Wilson just for this. >>>>>> However, Chuck has been silent for some time now. >>>>> Maybe someone else could step forward. >>>>> >>>> For me this usually boiled down to that I had to do it myself. >>>> So if you have some spare time... >>> Not enough to become involved with MSYS development environment, >>> sorry. >> I will give it a try. >> >> regards, >> > > Hi, > > I have tried it, but I have a problem during the configure step. > Configure hangs forever during this step: > > checking whether strstr works in linear time... > > To reproduce: > 1. Download the files from http://waterlan.home.xs4all.nl/msys/m4/ in a > new folder. > 2. Make sure your msys packages are up to date, as mentioned in m4.README. > 3. Start an msys special shell with this command: msys.bat MSYS > 4. Start package creation in msys shell with this command: mgwport > m4-1.4.16-1.msysport almostall > > If somebody knows a fix, please let me know. > > regards, > > -- > Erwin Waterlander > http://waterlan.home.xs4all.nl/ > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
From: waterlan <wat...@xs...> - 2013-02-21 10:51:33
|
Alexpux schreef op 2013-02-21 03:22: > I have successfully builded m4-1.4.16. If you need I can upload > source package with script and patch that works. > Regards, Alexey. > That could help. Yes, please. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Alexpux <al...@gm...> - 2013-02-21 11:26:59
|
You can download source package for m4-1.4.16 from https://www.dropbox.com/s/dd6plg4ap59jd5a/m4-1.4.16-1-msys-1.0.17-src.tar.lzma 21.02.2013, в 14:51, waterlan <wat...@xs...> написал(а): > Alexpux schreef op 2013-02-21 03:22: >> I have successfully builded m4-1.4.16. If you need I can upload >> source package with script and patch that works. >> Regards, Alexey. >> > > That could help. Yes, please. > > regards, > > -- > Erwin Waterlander > http://waterlan.home.xs4all.nl/ > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
From: Erwin W. <wat...@xs...> - 2013-02-21 18:39:48
|
Op 21-2-2013 12:26, Alexpux schreef: > You can download source package for m4-1.4.16 from https://www.dropbox.com/s/dd6plg4ap59jd5a/m4-1.4.16-1-msys-1.0.17-src.tar.lzma > > Thanks, I got it. -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Erwin W. <wat...@xs...> - 2013-02-21 21:05:34
|
Alexpux schreef, Op 21-2-2013 12:26: > You can download source package for m4-1.4.16 from https://www.dropbox.com/s/dd6plg4ap59jd5a/m4-1.4.16-1-msys-1.0.17-src.tar.lzma > > Hi, You used the original packaging script. It makes for me no difference. In my msys shell configure hangs at "checking whether strstr works in linear time...". Also with the script you used. I don't understand how it worked for you. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Greg C. <gch...@sb...> - 2013-02-21 22:15:51
|
On 2013-02-20 22:06Z, Erwin Waterlander wrote: [...] > Configure hangs forever during this step: > > checking whether strstr works in linear time... According to this report, it can take several minutes: http://sourceware.org/ml/libc-alpha/2012-06/msg00772.html | > user 4m21.060s | | Yes, if an strstr implementation takes more than 4 minutes to search for | a 100000 byte long string in a 2000000 byte long string, it's quadratic | behaviour. That message also shows the source code, which contains this comment: | > | /* Failure to compile this test due to missing alarm is okay, | > | since all such platforms (mingw) also have quadratic strstr. */ | > | signal (SIGALRM, quit); The "mingw" comment wouldn't apply to MSYS, but perhaps MSYS's version of newlib has a strstr() that performs poorly on this test. You may wish to experiment with lower values of 'm' here: | > | size_t m = 1000000; | > | char *haystack = (char *) malloc (2 * m + 2); | > | char *needle = (char *) malloc (m + 2); If it works quickly with m=1000, and is noticeably slow with m=100000, then you could extrapolate how long m=1000000 would take...in order to guess whether the problem lies here, or elsewhere. I'm not set up to compile for MSYS, or I'd do it myself, sorry. |
From: Erwin W. <wat...@xs...> - 2013-02-21 23:05:10
|
Greg Chicares schreef, Op 21-2-2013 23:15: > On 2013-02-20 22:06Z, Erwin Waterlander wrote: > [...] >> Configure hangs forever during this step: >> >> checking whether strstr works in linear time... > According to this report, it can take several minutes: > > http://sourceware.org/ml/libc-alpha/2012-06/msg00772.html > | > user 4m21.060s > | > | Yes, if an strstr implementation takes more than 4 minutes to search for > | a 100000 byte long string in a 2000000 byte long string, it's quadratic > | behaviour. > > That message also shows the source code, which contains this comment: > > | > | /* Failure to compile this test due to missing alarm is okay, > | > | since all such platforms (mingw) also have quadratic strstr. */ > | > | signal (SIGALRM, quit); > > The "mingw" comment wouldn't apply to MSYS, but perhaps MSYS's version > of newlib has a strstr() that performs poorly on this test. > > You may wish to experiment with lower values of 'm' here: > > | > | size_t m = 1000000; > | > | char *haystack = (char *) malloc (2 * m + 2); > | > | char *needle = (char *) malloc (m + 2); > > If it works quickly with m=1000, and is noticeably slow with m=100000, > then you could extrapolate how long m=1000000 would take...in order to > guess whether the problem lies here, or elsewhere. I'm not set up to > compile for MSYS, or I'd do it myself, sorry. > Hi Greg, You solved the problem. The check was already running for three and a half hours on my 2 year old desktop. By changing m to 1000 the test finished in a second on my 6 year old laptop. Thanks! regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Earnie B. <ea...@us...> - 2013-02-22 03:50:54
|
On Thu, Feb 21, 2013 at 6:05 PM, Erwin Waterlander wrote: > Greg Chicares schreef, Op 21-2-2013 23:15: >> On 2013-02-20 22:06Z, Erwin Waterlander wrote: >> [...] >>> Configure hangs forever during this step: >>> >>> checking whether strstr works in linear time... >> According to this report, it can take several minutes: >> >> http://sourceware.org/ml/libc-alpha/2012-06/msg00772.html >> | > user 4m21.060s >> | >> | Yes, if an strstr implementation takes more than 4 minutes to search for >> | a 100000 byte long string in a 2000000 byte long string, it's quadratic >> | behaviour. >> >> That message also shows the source code, which contains this comment: >> >> | > | /* Failure to compile this test due to missing alarm is okay, >> | > | since all such platforms (mingw) also have quadratic strstr. */ >> | > | signal (SIGALRM, quit); >> >> The "mingw" comment wouldn't apply to MSYS, but perhaps MSYS's version >> of newlib has a strstr() that performs poorly on this test. >> >> You may wish to experiment with lower values of 'm' here: >> >> | > | size_t m = 1000000; >> | > | char *haystack = (char *) malloc (2 * m + 2); >> | > | char *needle = (char *) malloc (m + 2); >> >> If it works quickly with m=1000, and is noticeably slow with m=100000, >> then you could extrapolate how long m=1000000 would take...in order to >> guess whether the problem lies here, or elsewhere. I'm not set up to >> compile for MSYS, or I'd do it myself, sorry. >> > > Hi Greg, > > You solved the problem. The check was already running for three and a > half hours on my 2 year old desktop. By changing m to 1000 the test > finished in a second on my 6 year old laptop. Thanks! I remember the issue now. I thought this had been taken care of with updates to autoconf itself. I must be wrong. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Erwin W. <wat...@xs...> - 2013-02-22 07:15:48
|
Op 22-2-2013 4:50, Earnie Boyd schreef: > On Thu, Feb 21, 2013 at 6:05 PM, Erwin Waterlander wrote: >> Hi Greg, >> >> You solved the problem. The check was already running for three and a >> half hours on my 2 year old desktop. By changing m to 1000 the test >> finished in a second on my 6 year old laptop. Thanks! > I remember the issue now. I thought this had been taken care of with > updates to autoconf itself. I must be wrong. > I had tried msys autoconf 2.65-1, 2.67-1, and 2.68-1. None of these worked. -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Keith M. <kei...@us...> - 2013-02-22 18:41:49
|
On 21/02/13 23:05, Erwin Waterlander wrote: > Greg Chicares schreef, Op 21-2-2013 23:15: >> On 2013-02-20 22:06Z, Erwin Waterlander wrote: >> [...] >>> Configure hangs forever during this step: >>> >>> checking whether strstr works in linear time... >> >> [...] >> You may wish to experiment with lower values of 'm' here: >> >> | > | size_t m = 1000000; >> | > | char *haystack = (char *) malloc (2 * m + 2); >> | > | char *needle = (char *) malloc (m + 2); >> >> If it works quickly with m=1000, and is noticeably slow with m=100000, >> then you could extrapolate how long m=1000000 would take...in order to >> guess whether the problem lies here, or elsewhere. I'm not set up to >> compile for MSYS, or I'd do it myself, sorry. > > You solved the problem. The check was already running for three and a > half hours on my 2 year old desktop. By changing m to 1000 the test > finished in a second on my 6 year old laptop. Thanks! What is the outcome of the test, after you make this adjustment? From the foregoing, it's apparent that MSYS' strstr runs in quadratic time, so we would expect a result of "no". If your adjustment results in a fake outcome of "yes", what is the impact for the m4 you've built? Is there an autoconf cache variable you can preload, to force the "no" outcome? If so, it may be prudent to assign it accordingly. -- Regards, Keith. |
From: Erwin W. <wat...@xs...> - 2013-02-22 19:03:19
|
Op 22-2-2013 19:41, Keith Marshall schreef: > On 21/02/13 23:05, Erwin Waterlander wrote: >> Greg Chicares schreef, Op 21-2-2013 23:15: >>> On 2013-02-20 22:06Z, Erwin Waterlander wrote: >>> [...] >>>> Configure hangs forever during this step: >>>> >>>> checking whether strstr works in linear time... >>> [...] >>> You may wish to experiment with lower values of 'm' here: >>> >>> | > | size_t m = 1000000; >>> | > | char *haystack = (char *) malloc (2 * m + 2); >>> | > | char *needle = (char *) malloc (m + 2); >>> >>> If it works quickly with m=1000, and is noticeably slow with m=100000, >>> then you could extrapolate how long m=1000000 would take...in order to >>> guess whether the problem lies here, or elsewhere. I'm not set up to >>> compile for MSYS, or I'd do it myself, sorry. >> You solved the problem. The check was already running for three and a >> half hours on my 2 year old desktop. By changing m to 1000 the test >> finished in a second on my 6 year old laptop. Thanks! > What is the outcome of the test, after you make this adjustment? The outcome was yes. > From the foregoing, it's apparent that MSYS' strstr runs in quadratic > time, so we would expect a result of "no". If your adjustment results > in a fake outcome of "yes", what is the impact for the m4 you've built? I don't know. Would it have impact at all? How different would this m4 be from the 1.4.14 we already have? > Is there an autoconf cache variable you can preload, to force the "no" > outcome? If so, it may be prudent to assign it accordingly. > I don't know. -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Erwin W. <wat...@xs...> - 2013-02-22 19:55:54
|
Op 22-2-2013 20:03, Erwin Waterlander schreef: > Op 22-2-2013 19:41, Keith Marshall schreef: >> On 21/02/13 23:05, Erwin Waterlander wrote: >>> Greg Chicares schreef, Op 21-2-2013 23:15: >>>> On 2013-02-20 22:06Z, Erwin Waterlander wrote: >>>> [...] >>>>> Configure hangs forever during this step: >>>>> >>>>> checking whether strstr works in linear time... >>>> [...] >>>> You may wish to experiment with lower values of 'm' here: >>>> >>>> | > | size_t m = 1000000; >>>> | > | char *haystack = (char *) malloc (2 * m + 2); >>>> | > | char *needle = (char *) malloc (m + 2); >>>> >>>> If it works quickly with m=1000, and is noticeably slow with m=100000, >>>> then you could extrapolate how long m=1000000 would take...in order to >>>> guess whether the problem lies here, or elsewhere. I'm not set up to >>>> compile for MSYS, or I'd do it myself, sorry. >>> You solved the problem. The check was already running for three and a >>> half hours on my 2 year old desktop. By changing m to 1000 the test >>> finished in a second on my 6 year old laptop. Thanks! >> What is the outcome of the test, after you make this adjustment? > The outcome was yes. When I set the m to 100000 it completes in a minute and the outcome is no. I will set it to 100000. > >> From the foregoing, it's apparent that MSYS' strstr runs in quadratic >> time, so we would expect a result of "no". If your adjustment results >> in a fake outcome of "yes", what is the impact for the m4 you've built? > I don't know. Would it have impact at all? > How different would this m4 be from the 1.4.14 we already have? > >> Is there an autoconf cache variable you can preload, to force the "no" >> outcome? If so, it may be prudent to assign it accordingly. >> > I don't know. > -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Keith M. <kei...@us...> - 2013-02-22 20:28:41
|
On 22/02/13 19:03, Erwin Waterlander wrote: [strstr() running in linear vs. quadratic time] >> What is the outcome of the test, after you make this adjustment? > > The outcome was yes. Which is bad, because... >> From the foregoing, it's apparent that MSYS' strstr runs in quadratic >> time, so we would expect a result of "no". If your adjustment results >> in a fake outcome of "yes", what is the impact for the m4 you've built? > > I don't know. Would it have impact at all? You've already witnessed the impact, in your configure run: potential for dramatically slow strstr() searches while running m4. > How different would this m4 be from the 1.4.14 we already have? I don't know. The test case is extreme, but it's intent is to weed out strstr() implementations which run in quadratic time, and to substitute a gnulib replacement, which is claimed to run in linear time. I don't know if Chuck built m4-1.4.14 with that replacement, or not. >> Is there an autoconf cache variable you can preload, to force the "no" >> outcome? If so, it may be prudent to assign it accordingly. > > I don't know. There is. You can find it by looking in config.log, as I did after I downloaded m4-1.4.16 from the GNU canonical source, and configured it for a native Linux hosted build. You can force configure to skip the slow test, and assume the "no" outcome by adding: $ ../configure gl_cv_func_strstr_linear=no ... followed by any other options you need to specify, to your configure command line; (this example assumes you build in a subdirectory of the top source directory). -- Regards, Keith. |
From: Erwin W. <wat...@xs...> - 2013-02-22 21:43:31
|
Keith Marshall schreef, Op 22-2-2013 21:28: > On 22/02/13 19:03, Erwin Waterlander wrote: > [strstr() running in linear vs. quadratic time] >>> What is the outcome of the test, after you make this adjustment? >> The outcome was yes. > Which is bad, because... > >>> From the foregoing, it's apparent that MSYS' strstr runs in quadratic >>> time, so we would expect a result of "no". If your adjustment results >>> in a fake outcome of "yes", what is the impact for the m4 you've built? >> I don't know. Would it have impact at all? > You've already witnessed the impact, in your configure run: potential > for dramatically slow strstr() searches while running m4. > >> How different would this m4 be from the 1.4.14 we already have? > I don't know. The test case is extreme, but it's intent is to weed out > strstr() implementations which run in quadratic time, and to substitute > a gnulib replacement, which is claimed to run in linear time. I don't > know if Chuck built m4-1.4.14 with that replacement, or not. He did not. But in 1.4.14 the test is different and results in a 'no' in a few seconds. > >>> Is there an autoconf cache variable you can preload, to force the "no" >>> outcome? If so, it may be prudent to assign it accordingly. >> I don't know. > There is. You can find it by looking in config.log, as I did after I > downloaded m4-1.4.16 from the GNU canonical source, and configured it > for a native Linux hosted build. You can force configure to skip the > slow test, and assume the "no" outcome by adding: > > $ ../configure gl_cv_func_strstr_linear=no ... > > followed by any other options you need to specify, to your configure > command line; (this example assumes you build in a subdirectory of the > top source directory). > Thanks! configure gl_cv_func_strstr_linear=no results in a (cached) no. That is better than playing with the value of m. A value of 100000 gave a 'no' on my desktop, and a 'yes' on my slow laptop. The option doesn't need to be in the beginning. You can also add it as a last option. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Keith M. <kei...@us...> - 2013-02-22 22:03:40
|
On 22/02/13 21:43, Erwin Waterlander wrote: > Thanks! configure gl_cv_func_strstr_linear=no results in a (cached) no. > That is better than playing with the value of m. A value of 100000 gave > a 'no' on my desktop, and a 'yes' on my slow laptop. The option doesn't > need to be in the beginning. You can also add it as a last option. That would be true in general: the arguments to configure are mutually independent, and may be specified in any order. -- Regards, Keith. |