From: Ibrahim H. <sal...@ya...> - 2007-07-04 17:40:06
|
Greetings ! I was running the 'official distribution' of MinGW/MSYS but encountered autoconf build problems. I then switched to mingw-install-20060210 but I encountered similar problems as indicated below. I would appreciate any pointers on the cause of the 'all-recursive error' and how to go about fixing it. A copy of my /etc/profile, /etc/fstab and PATH are indicated below. Please I need a little tutorial on how msys gets the appropriate libraries especially the perl5/5.6.1 libraries. ********************************************** Output of Make in autoconf-2.61 ****************************************** Making all in bin make[1]: Entering directory `/c/work/autoconf-2.61/bin' make[2]: Entering directory `/c/work/autoconf-2.61' make[2]: Leaving directory `/c/work/autoconf-2.61' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/c/work/autoconf-2.61/bin' Making all in . make[1]: Entering directory `/c/work/autoconf-2.61' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/c/work/autoconf-2.61' Making all in lib make[1]: Entering directory `/c/work/autoconf-2.61/lib' make[2]: Entering directory `/c/work/autoconf-2.61' make[2]: Leaving directory `/c/work/autoconf-2.61' Making all in Autom4te make[2]: Entering directory `/c/work/autoconf-2.61/lib/Autom4te' make[3]: Entering directory `/c/work/autoconf-2.61' make[3]: Leaving directory `/c/work/autoconf-2.61' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/c/work/autoconf-2.61/lib/Autom4te' Making all in m4sugar make[2]: Entering directory `/c/work/autoconf-2.61/lib/m4sugar' make[3]: Entering directory `/c/work/autoconf-2.61' make[3]: Leaving directory `/c/work/autoconf-2.61' autom4te_perllibdir='../..'/lib AUTOM4TE_CFG='../../lib/autom4te.cfg' ../../bin/autom4te -B '../..'/lib -B '../..'/lib \ --language=m4sugar \ --freeze \ --output=m4sugar.m4f autom4te: freezing produced output: autom4te: autom4te: autom4te: autom4te: autom4te: make[2]: *** [m4sugar.m4f] Error 1 make[2]: Leaving directory `/c/work/autoconf-2.61/lib/m4sugar' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/work/autoconf-2.61/lib' make: *** [all-recursive] Error 1 *********************************** /etc/profile ********************************************************** # Copyright (C) 2001, 2002 Earnie Boyd <ea...@us...> # This file is part of the Minimal SYStem. # http://www.mingw.org/msys.shtml # # File: profile # Description: Shell environment initialization script # Last Revised: 2002.05.04 if [ -z "$MSYSTEM" ]; then MSYSTEM=MINGW32 fi # My decision to add a . to the PATH and as the first item in the path list # is to mimick the Win32 method of finding executables. # # I filter the PATH value setting in order to get ready for self hosting the # MSYS runtime and wanting different paths searched first for files. if [ $MSYSTEM == MINGW32 ]; then export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH" else export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH" fi if [ -z "$USERNAME" ]; then LOGNAME="`id -un`" else LOGNAME="$USERNAME" fi # Set up USER's home directory if [ -z "$HOME" ]; then HOME="/home/$LOGNAME" fi if [ ! -d "$HOME" ]; then mkdir -p "$HOME" fi if [ "x$HISTFILE" == "x/.bash_history" ]; then HISTFILE=$HOME/.bash_history fi export HOME LOGNAME MSYSTEM HISTFILE for i in /etc/profile.d/*.sh ; do if [ -f $i ]; then . $i fi done export MAKE_MODE=unix export PS1='\[\033]0;$MSYSTEM:\w\007 \033[32m\]\u@\h \[\033[33m\w\033[0m\] $ ' alias clear=clsb cd "$HOME" ************************************* /etc/fstab ******************************************************** #fstab.sample #This is a sample file for /etc/fstab. #Currently /etc/fstab is only read during dll initialization. #I will eventually watch the directory for changes and reread the file. #The line format is simple in that you give the Win32 path, followed by one or #more space or tab delimiter, followed by the mount point. Mount points in #typical UNIX environments must be a physical name on a drive before it can #actually be used as a mount point. In this implementation the "must exist" #requirement isn't enforced, however, it will be an aide to such programs as #find and readline's tab completion if it does exist. #You can use a # as the first character on the line as a comment indicator. #Blank lines are ignored. #Win32_Path Mount_Point c:/msys/1.0 /usr c:/msys/1.0/mingw /mingw #c:/ActiveState/perl /perl *********************************** echo $PATH ********************************************************************** .:/usr/local/bin:/mingw/bin:/bin:/c/Program Files/TeXLive/bin/win32:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/matlab6p5/bin/win32:/c/MSSQL/BINN:/c/SNA/system:/c/php:/c/Program Files/Common Files/Autodesk Shared/:/c/Program Files/MySQL/MySQL Server 5.0/bin:/c/Program Files/Microsoft Visual Studio/VC98/bin:/c/Program Files/Microsoft Visual Studio/COMMON/MSDEV98/bn:/c/utils:/c/Perl/bin:/c/PFWSCH:/c/PFW BTW, /c/Perl/ which is activestate perl have been moved to /c/perl.old so is no longer on the PATH. Please how can I echo the library and include paths and check what is being probed for by msys perl 5.6.1 ? ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail |
From: Keith M. <kei...@to...> - 2007-07-05 09:25:20
|
Ibrahim Hassan wrote: > I was running the 'official distribution' of MinGW/MSYS > but encountered autoconf build problems. I then switched to > mingw-install-20060210 but I encountered similar problems We don't support that unofficial distribution, but since you saw similar problems with our official releases, we will try to help. > as indicated below. I've snipped the info you attached; I don't see anything there which might explain *why* your build is failing. > I would appreciate any pointers on the cause of the > 'all-recursive error' No idea. All I can see is that it did fail, but no clues as to why. IIRC, it was autoconf-2.61 that you were experiencing problems with, and that builds OOTB for me. Please tell us the complete and exact sequence of commands you used, from unpacking the tarball, all the way through to the failing make; copy-and-paste, don't transcribe, and leave nothing out, not even a `cd' you think may be innocuous; attach the output from `msysinfo all'. > Please I need a little tutorial on how msys gets the > appropriate libraries especially the perl5/5.6.1 libraries. I'm not a perl programmer, so I don't know. I do know that autom4te, which is the component of autoconf you originally reported a problem with, requires perl, and your problem appears to have arisen from confusion between ActiveState perl and msysDTK perl on your machine. I installed the msysDTK, in the same directory tree as MSYS itself; that provides the only perl interpreter on my machine, and it just works. > /c/Perl/ which is activestate perl have been moved to > /c/perl.old so is no longer on the PATH. Are there any other environment variables, which may affect the way perl works? If so, get rid of them too, and trim the PATH to the bare minimum you need for MSYS to work. Sorry, I can't think of anything else to suggest. Regards, Keith. |
From: haibin z. <dr...@ya...> - 2007-07-05 14:05:00
|
I know the problem, it's the problem in m4, he must use m4 version >= 1.4.7 Regards Keith MARSHALL <kei...@to...> 写道: Ibrahim Hassan wrote: > I was running the 'official distribution' of MinGW/MSYS > but encountered autoconf build problems. I then switched to > mingw-install-20060210 but I encountered similar problems We don't support that unofficial distribution, but since you saw similar problems with our official releases, we will try to help. > as indicated below. I've snipped the info you attached; I don't see anything there which might explain *why* your build is failing. > I would appreciate any pointers on the cause of the > 'all-recursive error' No idea. All I can see is that it did fail, but no clues as to why. IIRC, it was autoconf-2.61 that you were experiencing problems with, and that builds OOTB for me. Please tell us the complete and exact sequence of commands you used, from unpacking the tarball, all the way through to the failing make; copy-and-paste, don't transcribe, and leave nothing out, not even a `cd' you think may be innocuous; attach the output from `msysinfo all'. > Please I need a little tutorial on how msys gets the > appropriate libraries especially the perl5/5.6.1 libraries. I'm not a perl programmer, so I don't know. I do know that autom4te, which is the component of autoconf you originally reported a problem with, requires perl, and your problem appears to have arisen from confusion between ActiveState perl and msysDTK perl on your machine. I installed the msysDTK, in the same directory tree as MSYS itself; that provides the only perl interpreter on my machine, and it just works. > /c/Perl/ which is activestate perl have been moved to > /c/perl.old so is no longer on the PATH. Are there any other environment variables, which may affect the way perl works? If so, get rid of them too, and trim the PATH to the bare minimum you need for MSYS to work. Sorry, I can't think of anything else to suggest. Regards, Keith. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Mingw-msys mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-msys --------------------------------- 抢注雅虎免费邮箱3.5G容量,20M附件! |
From: Keith M. <kei...@to...> - 2007-07-05 14:55:12
|
Haibin Zhang wrote: > I know the problem, it's the problem in m4, > he must use m4 version >= 1.4.7 If that is true, can you explain why it [autoconf-2.61] builds OOTB for me, still using m4 with version == 1.4, as included in msysDTK-1.0.1? The error messages posted previously did point to a possible perl conflict between the MSYS implementation and ActiveState perl, which was also installed. Regards, Keith. |
From: haibin z. <dr...@ya...> - 2007-07-06 02:47:13
|
Keith MARSHALL <kei...@to...> 写道: Haibin Zhang wrote: > I know the problem, it's the problem in m4, > he must use m4 version >= 1.4.7 If that is true, can you explain why it [autoconf-2.61] builds OOTB for me, still using m4 with version == 1.4, as included in msysDTK-1.0.1? The error messages posted previously did point to a possible perl conflict between the MSYS implementation and ActiveState perl, which was also installed. I have tested autoconf with m4-1.4 and ActiveState perl , it can't be used. and autoconf team said that autconf-2.61 must use m4-1.4.7 in ChangeLog (I also tested m4-1.4.6 can't be used with autoconf-2.61) If you want to use autconf-2.61 in Mingw, you should depend these packages: m4-1.4.7 perl-5.6.1 (in msysDTK-1.0.1, don't use ActiveState perl or build by yourself) and you must remove other packages in msysDTK-1.0.1(beacuse many packages are very old), if you don't do that, it will occur error. Regards Zhang Haibin Regards, Keith. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Mingw-msys mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-msys --------------------------------- 抢注雅虎免费邮箱-3.5G容量,20M附件! |
From: Keith M. <kei...@to...> - 2007-07-06 09:50:16
|
Haibin Zhang wrote, quoting me: >>> I know the problem, it's the problem in m4, >>> he must use m4 version >= 1.4.7 >> >> If that is true, can you explain why it [autoconf-2.61] builds >> OOTB for me, still using m4 with version == 1.4, as included in >> msysDTK-1.0.1? >> >> The error messages posted previously did point to a possible >> perl conflict between the MSYS implementation and ActiveState >> perl, which was also installed. > > I have tested autoconf with m4-1.4 and ActiveState perl , it can't > be used. I have been *using* autoconf-2.61, for several months now, in *real* production service, and with *exactly* the versions of m4 and perl as included in msysDTK-1.0.1, (i.e. m4-1.4, perl-5.6.1), and I have not yet encountered a single problem. (There was exactly one error, when I ran the autoconf-2.61 testsuite -- it was associated with a macro I've never used, can't recall which, and it hasn't troubled me in routine usage). > and autoconf team said that autconf-2.61 must use m4-1.4.7 > in ChangeLog I am aware of that recommendation, and no doubt the autoconf team have good reason to make it; I simply have not encountered it. > (I also tested m4-1.4.6 can't be used with autoconf-2.61) That is not borne out by my experience, although when I built m4-1.4.6, (as a MinGW app, not an MSYS app), and I ran its testsuite, I saw too many failures to encourage me to place it into regular service. > If you want to use autconf-2.61 in Mingw, you should depend these > packages: > > m4-1.4.7 > perl-5.6.1 (in msysDTK-1.0.1, don't use ActiveState perl > or build by yourself) I agree, in the case of perl. I'm not yet convinced about m4. If I do encounter a case which fails, then I will surely investigate the possibility that an m4 versioning issue is the culprit; until that happens, m4-1.4 will suffice. > and you must remove other packages in msysDTK-1.0.1 This simply is not true... > (beacuse many packages are very old), Yes, that is true. There are newer versions of some available in our snapshot repository: https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82724&release_id=158862 (but neither m4, nor perl is among them). You are welcome to use any of these today, but we will not package them until the MSYS-1.0.11 release has been finalised. > if you don't do that, it will occur error. You say this, but you offer no concrete evidence. BTW, when replying to postings on this list, could you please *mark* quoted text as such, rather than just indenting it ever so slightly; your indentation disappears from the HTML list archives, making the thread difficult to follow, at best, bordering on incomprehensible in general. Regards, Keith. |
From: haibin z. <dr...@ya...> - 2007-07-06 10:08:58
|
BTW, when replying to postings on this list, could you please *mark* quoted text as such, rather than just indenting it ever so slightly; your indentation disappears from the HTML list archives, making the thread difficult to follow, at best, bordering on incomprehensible in general. I don't want to show like this, It's auto format by yahoo, it's a very bad format. but I can't change it Regards Zhang HaiBin --------------------------------- 雅虎免费邮箱3.5G容量,20M附件! |
From: Tuomo L. <dj...@ik...> - 2007-07-06 11:22:55
|
haibin zhang wrote: > I don't want to show like this, It's auto format by yahoo, it's a very bad format. but I can't change it Yes, you can. If you change Options->Mail->General Preferences->Composing E-mails to "Compose messages as *plain text*", the quotations will show up correctly. -- Tuomo ... Everyone is gifted. Some open the package sooner. |
From: haibin z. <dr...@ya...> - 2007-07-08 14:43:12
|
--- Tuomo Latto <dj...@ik...>写道: > haibin zhang wrote: > > I don't want to show like this, It's auto format > by yahoo, it's a very bad format. but I can't change > it > > Yes, you can. > If you change Options->Mail->General > Preferences->Composing E-mails > to "Compose messages as *plain text*", the > quotations will show > up correctly. Good, thank you very much. > > -- > Tuomo > > ... Everyone is gifted. Some open the package > sooner. > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 > express and take > control of your XML. No limits. Just data. Click to > get it now. > http://sourceforge.net/powerbar/db2/> _______________________________________________ > Mingw-msys mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-msys > ___________________________________________________________ Mp3疯狂搜-新歌热歌高速下 http://music.yahoo.com.cn/?source=mail_mailbox_footer |
From: Keith M. <kei...@us...> - 2007-07-09 21:55:59
|
On Sunday 08 July 2007 15:42, haibin zhang wrote: > > haibin zhang wrote: > > > I don't want to show like this, It's auto format > > > > by yahoo, it's a very bad format. but I can't change > > it > > > > Yes, you can. > > If you change Options->Mail->General > > Preferences->Composing E-mails > > to "Compose messages as *plain text*", the > > quotations will show > > up correctly. > > Good, thank you very much. Great. perhaps, now that you've sorted that one out, you could give some thought to trimming the quotes -- there's no need for persistent recycling of sig lines, and SF advertising junk. Regards, Keith. |
From: Keith M. <kei...@to...> - 2007-07-06 12:02:47
|
Earlier, I wrote: > There was exactly one error, when > I ran the autoconf-2.61 testsuite -- it was associated with a > macro I've never used, can't recall which, ... FTR, I've run the testsuite again, (all 1 hr 45 mins of it): | ## ------------- ## | ## Test results. ## | ## ------------- ## | | ERROR: 293 tests were run, | 5 failed (4 expected failures). | 4 tests were skipped. | ## -------------------------- ## | ## testsuite.log was created. ## | ## -------------------------- ## The only unexpected failure was: | 278: AC_FUNC_MEMCMP ok | 279: AC_FUNC_MKTIME FAILED (acfunctions.at:26) | 280: AC_FUNC_MMAP ok If I can't see an obvious relationship between the m4-1.4 version issue, and this failure, then... | Please send `tests/testsuite.log' and all information you think | might help: | | To: <bug...@gn...> | Subject: [GNU Autoconf 2.61] testsuite: 279 failed ...I shall do this. Regards, Keith. |
From: Keith M. <kei...@us...> - 2007-07-09 21:16:28
|
On Friday 06 July 2007 12:57, Keith MARSHALL wrote: > The only unexpected failure [in autoconf-2.61 testsuite] was: > > | =A0278: AC_FUNC_MEMCMP =A0 =A0ok > | =A0279: AC_FUNC_MKTIME =A0 =A0FAILED (acfunctions.at:26) > | =A0280: AC_FUNC_MMAP =A0 =A0 =A0ok > > If I can't see an obvious relationship between the m4-1.4 version > issue, and this failure, then... Confirmed; this failure *is* m4 version induced. It seems that this=20 test alone, of the 297 in the testsuite, requires a later version of m4=20 than the m4-1.4 included in msysDTK-1.0.1; (on my GNU/Linux box it=20 passes, with m4-1.4.3). I've subsequently discovered that Earnie *did* post an updated MSYS=20 build of m4-1.4.7; unlike most of the remaining MSYS-1.0.11 preleases,=20 which are in the `snapshot' package set, this is in `current': http://downloads.sourceforge.net/mingw/m4-1.4.7-MSYS.tar.bz2 Dropping this into my MSYS /bin directory, in place of the v1.4 m4.exe,=20 allows autoconf-2.61 to build OOTB, and to completely pass all checks=20 in its testsuite. Regards, Keith. |
From: Keith M. <kei...@to...> - 2007-07-06 15:01:47
|
Haibin Zhang wrote, quoting me: >>> I know the problem, it's the problem in m4, >>> he must use m4 version >= 1.4.7 >> >> If that is true, can you explain why it [autoconf-2.61] builds >> OOTB for me, still using m4 with version == 1.4, as included in >> msysDTK-1.0.1? >> >> The error messages posted previously did point to a possible >> perl conflict between the MSYS implementation and ActiveState >> perl, which was also installed. > > I have tested autoconf with m4-1.4 and ActiveState perl , it can't > be used. Ok. I've followed up on this a bit, and I think I can successfully reproduce Ibrahim Hassan's problem: -----8<-------------------------- $ pwd /home/keith $ cd build/autoconf-2.61 $ ./config.status --version GNU Autoconf config.status 2.61 configured by ../../autoconf-2.61/configure, generated by GNU Autoconf 2.61, with options "" $ make clean [...output snipped...] $ ./config.status --recheck [...output snipped...] $ ./config.status [...output snipped...] $ make [...] Making all in m4sugar make[2]: Entering directory `/home/keith/build/autoconf-2.61/lib/m4sugar' make[3]: Entering directory `/home/keith/build/autoconf-2.61' make[3]: Leaving directory `/home/keith/build/autoconf-2.61' autom4te_perllibdir='../../../../autoconf-2.61'/lib \ AUTOM4TE_CFG='../../lib/autom4te.cfg' \ ../../bin/autom4te -B '../..'/lib \ -B '../../../../autoconf-2.61'/lib \ --language=m4sugar \ --freeze \ --output=m4sugar.m4f autom4te: freezing produced output: autom4te: [...above line repeats 407 more times...] make[2]: *** [m4sugar.m4f] Error 1 make[2]: Leaving directory `/home/keith/build/autoconf-2.61/lib/m4sugar' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/keith/build/autoconf-2.61/lib' make: *** [all-recursive] Error 1 -----8<-------------------------- I achieved this, by building and installing a MinGW native m4-1.4.9, which built OOTB, and passed its testsuite with flying colours; (just a note to the effect that carriage returns were being ignored[1], and two `syscmd' checks were skipped because semantics were not unix; otherwise, all checks passed successfully). Well, that's all fine and dandy, but it sure *doesn't* work, when used for real to build autoconf-2.61! If I then uninstall the m4-1.4.9, (from /usr/local/bin, which precedes /bin in my PATH), thus reverting to the original MSYS build of m4-1.4, I can again successfully build and deploy autoconf-2.61. So, it would seem that my experience diammetrically contradicts Haibin Zhang's assertion: with m4-1.4, (from msysDTK-1.0.1), everything seems to work as expected, (bar one as yet unexplained test case failure); with m4 >= 1.4.7, (m4-1.4.9, natively built with MinGW in my case), it does *not* work[1]. Regards, Keith. [1] There may be a clue in that `Ignoring carriage returns' message, from the m4-1.4.9 testsuite, and the `freezing produced output', with a consistently reproducible 408 blank lines following, from autom4te; could that output from autom4te be carriage returns, from CRLF output in m4, which m4 expects to be ignored, but autom4te doesn't? |
From: haibin z. <dr...@ya...> - 2007-07-08 15:04:47
|
--- Keith MARSHALL <kei...@to...>写道: > > > > > Haibin Zhang wrote, quoting me: > >>> I know the problem, it's the problem in m4, > >>> he must use m4 version >= 1.4.7 > >> > >> If that is true, can you explain why it > [autoconf-2.61] builds > >> OOTB for me, still using m4 with version == 1.4, > as included in > >> msysDTK-1.0.1? > >> > >> The error messages posted previously did point to > a possible > >> perl conflict between the MSYS implementation and > ActiveState > >> perl, which was also installed. > > > > I have tested autoconf with m4-1.4 and ActiveState > perl , it can't > > be used. > > Ok. I've followed up on this a bit, and I think I > can successfully > reproduce Ibrahim Hassan's problem: > > -----8<-------------------------- > > $ pwd > /home/keith > > $ cd build/autoconf-2.61 > > $ ./config.status --version > GNU Autoconf config.status 2.61 > configured by ../../autoconf-2.61/configure, > generated by GNU Autoconf 2.61, > with options "" > > $ make clean > [...output snipped...] > > $ ./config.status --recheck > [...output snipped...] > > $ ./config.status > [...output snipped...] > > $ make > [...] > Making all in m4sugar > make[2]: Entering directory > `/home/keith/build/autoconf-2.61/lib/m4sugar' > make[3]: Entering directory > `/home/keith/build/autoconf-2.61' > make[3]: Leaving directory > `/home/keith/build/autoconf-2.61' > autom4te_perllibdir='../../../../autoconf-2.61'/lib > \ > AUTOM4TE_CFG='../../lib/autom4te.cfg' > \ > ../../bin/autom4te -B '../..'/lib > \ > -B '../../../../autoconf-2.61'/lib > \ > --language=m4sugar > \ > --freeze > \ > --output=m4sugar.m4f > autom4te: freezing produced output: > autom4te: > > [...above line repeats 407 more times...] > > make[2]: *** [m4sugar.m4f] Error 1 > make[2]: Leaving directory > `/home/keith/build/autoconf-2.61/lib/m4sugar' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/home/keith/build/autoconf-2.61/lib' > make: *** [all-recursive] Error 1 > > -----8<-------------------------- > > I achieved this, by building and installing a MinGW > native m4-1.4.9, > which built OOTB, and passed its testsuite with > flying colours; (just > a note to the effect that carriage returns were > being ignored[1], and > two `syscmd' checks were skipped because semantics > were not unix; > otherwise, all checks passed successfully). Well, > that's all fine > and dandy, but it sure *doesn't* work, when used for > real to build > autoconf-2.61! > > If I then uninstall the m4-1.4.9, (from > /usr/local/bin, which precedes > /bin in my PATH), thus reverting to the original > MSYS build of m4-1.4, > I can again successfully build and deploy > autoconf-2.61. > > So, it would seem that my experience diammetrically > contradicts Haibin > Zhang's assertion: with m4-1.4, (from > msysDTK-1.0.1), everything seems > to work as expected, (bar one as yet unexplained > test case failure); > with m4 >= 1.4.7, (m4-1.4.9, natively built with > MinGW in my case), it > does *not* work[1]. As I know , you must build m4-1.4.9 with gcc-2.95.3, It can't work when you build with gcc-3.4.X. I have reported the bug to m4 team , but they said they can't help me to resolve this problem. why m4-1.4.X can work building with gcc-2.95.3, but can't work building with gcc-3.4.X, I guess that the error is maybe in path resolve I guess that m4-1.4.X can resolve path /usr/bin as /usr/bin in gcc-2.95.3 , but it many resolve path /usr/bin as c:/msys/bin in gcc-3.4.X , so m4-1.4.X can't be used . but I don't test with this , I only guess it. Regards Zhang HaiBin ___________________________________________________________ 雅虎免费邮箱3.5G容量,20M附件! http://cn.mail.yahoo.com/ |
From: Keith M. <kei...@us...> - 2007-07-09 21:52:03
|
On Sunday 08 July 2007 16:04, haibin zhang wrote: > As I know , you must build m4-1.4.9 with gcc-2.95.3, > It can't work when you build with gcc-3.4.X. No, this is not the case. Yes, there is a problem, but your evaluation=20 is completely wrong. You keep making these wild assessments, without=20 presenting any form of corroborating evidence; let *me* make a wild=20 guess: your gcc-2.95.3 is the MSYS development compiler; gcc-3.4.x is a=20 MinGW compiler, which is unsuitable for building MSYS components. > I have reported the bug to m4 team , but they said > they can't help me to resolve this problem. Nor should they, on the basis of your inadequate problem assessment. > why m4-1.4.X can work building with gcc-2.95.3, but > can't work building with gcc-3.4.X, I guess that the > error is maybe =C2=A0in path resolve Nope. You are way off beam here; it has nothing to do with path=20 resolution. The difference is in binary mode versus text mode for=20 standard stream I/O. > I guess that m4-1.4.X can resolve path /usr/bin as > /usr/bin in gcc-2.95.3 , but it many resolve path > /usr/bin as c:/msys/bin in gcc-3.4.X , so m4-1.4.X > can't be used . Again, no. When you build with the MSYS development compiler, I/O=20 defaults to binary, with LF only line endings; when you build with a=20 MinGW compiler, the default is text, hence CRLF line endings. Those=20 line ending differences completely explain the failure of the MinGW=20 built m4-1.4.9 to work correctly with autoconf. If I patch m4-1.4.9=20 sources, to force all standard streams, and all files opened by m4, to=20 binary mode, then recompile with MinGW's 3.4.5 compiler, the resulting=20 m4.exe seems to work perfectly well with autoconf-2.61. However, the=20 resulting m4 build does then fail four of its testsuite checks; in each=20 case, the reported failure does appear to be related to CRLF vs. LF=20 distinctions, for in each of the four cases, the expected and actual=20 output appear identical to the naked eye; (if I can devise an effective=20 strategy for capturing the respective streams, I'll try to compare them=20 with `od', but that's an exercise for another day). Regards, Keith. |
From: haibin z. <dr...@ya...> - 2007-07-10 03:26:20
|
--- Keith Marshall <kei...@us...>写道: > On Sunday 08 July 2007 16:04, haibin zhang wrote: > > As I know , you must build m4-1.4.9 with > gcc-2.95.3, > > It can't work when you build with gcc-3.4.X. > > No, this is not the case. Yes, there is a problem, > but your evaluation > is completely wrong. You keep making these wild > assessments, without > presenting any form of corroborating evidence; let > *me* make a wild > guess: your gcc-2.95.3 is the MSYS development > compiler; gcc-3.4.x is a > MinGW compiler, which is unsuitable for building > MSYS components. > > > I have reported the bug to m4 team , but they said > > they can't help me to resolve this problem. > > Nor should they, on the basis of your inadequate > problem assessment. > > > why m4-1.4.X can work building with gcc-2.95.3, > but > > can't work building with gcc-3.4.X, I guess that > the > > error is maybe in path resolve > > Nope. You are way off beam here; it has nothing to > do with path > resolution. The difference is in binary mode versus > text mode for > standard stream I/O. thank you very much > > > I guess that m4-1.4.X can resolve path /usr/bin as > > /usr/bin in gcc-2.95.3 , but it many resolve path > > /usr/bin as c:/msys/bin in gcc-3.4.X , so m4-1.4.X > > can't be used . > > Again, no. When you build with the MSYS development > compiler, I/O > defaults to binary, with LF only line endings; when > you build with a > MinGW compiler, the default is text, hence CRLF line > endings. Those > line ending differences completely explain the > failure of the MinGW > built m4-1.4.9 to work correctly with autoconf. If > I patch m4-1.4.9 > sources, to force all standard streams, and all > files opened by m4, to > binary mode, then recompile with MinGW's 3.4.5 > compiler, the resulting > m4.exe seems to work perfectly well with > autoconf-2.61. However, the > resulting m4 build does then fail four of its > testsuite checks; in each > case, the reported failure does appear to be related > to CRLF vs. LF > distinctions, for in each of the four cases, the > expected and actual > output appear identical to the naked eye; (if I can > devise an effective > strategy for capturing the respective streams, I'll > try to compare them > with `od', but that's an exercise for another day). Can we do opposite, compile gcc 3.4.X as MSYS development, so that can use gcc 3.4.X to compile m4-1.4.9 do you know how to compile gcc 3.4.X defaults to binary, with LF only line endings ? Regards Zhang HaiBin ___________________________________________________________ 抢注雅虎免费邮箱3.5G容量,20M附件! http://cn.mail.yahoo.com |
From: Keith M. <kei...@us...> - 2007-07-10 19:12:33
|
On Tuesday 10 July 2007 04:25, haibin zhang wrote: > Can we do opposite, compile gcc 3.4.X as MSYS > development, so that can use gcc 3.4.X to compile > m4-1.4.9 That would be a major undertaking, which is why we still use gcc-2.95.3 as our MSYS build compiler. > do you know how to compile gcc 3.4.X defaults to > binary, with LF only line endings ? You need to set _fmode to O_BINARY before opening any I/O streams, and you must also call _setmode for each of the pre-opened standard I/O streams. You can easily do this early in the main function, for any application which you want to exhibit this behaviour; I guess that it would be fairly trivial to modify the runtime startup module, to make this the default. However, if it was this simple, we would already have done it a long time ago; there are much more significant changes required, to create an MSYS development suite. Regards, Keith. |
From: haibin z. <dr...@ya...> - 2007-07-17 09:39:19
|
--- Keith Marshall <kei...@us...>写道: > On Tuesday 10 July 2007 04:25, haibin zhang wrote: > > Can we do opposite, compile gcc 3.4.X as MSYS > > development, so that can use gcc 3.4.X to compile > > m4-1.4.9 > > That would be a major undertaking, which is why we > still use gcc-2.95.3 > as our MSYS build compiler. > > > do you know how to compile gcc 3.4.X defaults to > > binary, with LF only line endings ? > > You need to set _fmode to O_BINARY before opening > any I/O streams, and > you must also call _setmode for each of the > pre-opened standard I/O > streams. You can easily do this early in the main > function, for any > application which you want to exhibit this > behaviour; I guess that it > would be fairly trivial to modify the runtime > startup module, to make > this the default. However, if it was this simple, > we would already > have done it a long time ago; there are much more > significant changes > required, to create an MSYS development suite. > I have found this information in msys.bat ================================================= rem ChangeLog: rem 2002.03.07 Earnie Boyd mailto:ea...@us... rem * Change the binmode setting to nobinmode. rem 2002.03.13 Earnie Boyd mailto:ea...@us... rem * Revert the nobinmode change. ================================================= Can we change nobinmode to binmode as default , like cygwin ,so that many unix program(include m4-1.4.9) can run directly in MSYS? Regards Zhang HaiBin ___________________________________________________________ 雅虎免费邮箱-3.5G容量,20M附件 http://cn.mail.yahoo.com/ |