From: Earnie B. <ea...@us...> - 2006-04-23 13:39:53
|
Developers, Especially Keith. I've just uploaded the above file to correct an issue with the 1.0.11 dll version that prevented libtool from correctly creating the .exe file in the build directory. The file contained in the tarball is named new-msys-1.0.dll and this needs to be copied to your msys-1.0.dll. http://prdownloads.sf.net/mingw/msys-1.0.dll-SNAP-1.0.11-2006.04.23.tar.bz2?download I suggest to preserve your working environment you do the following assuming you've installed msys at c:\msys\1.0: 1) cp -a /c/msys/1.0 /c/msys/test 2) download msys-1.0.dll-SNAP-1.0.11-2006.04.23.tar.bz2 to /tmp. 3) cd /tmp && tar -jxf msys-1.0.dll-SNAP-1.0.11-2006.04.23.tar.bz2 4) cp new-msys-1.0.dll /c/msys/test/bin/msys-1.0.dll 5) copy & paste the existing desktop icon 6) edit the properties of the copy to point to c:\msys\test. The snap contains a modification to munge the ``prefix'' variable to a windows path. I would like comment on this. The snap contains a patch by Max T. Woodbury specific to windows 98. Max is this still a valid patch? I'm talking about: <ChangeLog entry> 2005.07.05 Max T. Woodbury <mt...@us...> * fhandler.cc (fhandler_disk_file::open): Fake successful open on directories for !iswinnt. </ChangeLog entry> FWIW I'm giving up on trying to fix the PTY issue at least for the next five years. If someone else wants to give a shot at it please feel free; the problem plagues Cygwin as well. If you do take a look at it I suggest you take a look at the newer console API functions and make it work for XP and above. Versions lower than XP are sorely out of luck; that doesn't mean that XP and beyond isn't. http://prdownloads.sf.net/mingw/msys-1.0.dll-SNAP-1.0.11-2006.04.23.tar.bz2?download Earnie Boyd http://shop.siebunlimited.com |
From: Mohan E. <gnu...@th...> - 2006-04-23 14:30:20
|
Hi Earnie, >FWIW I'm giving up on trying to fix the PTY issue at least for the next >five years. If someone else wants to give a shot at it please feel >free; the problem plagues Cygwin as well. If you do take a look at it >I suggest you take a look at the newer console API functions and make >it work for XP and above. Versions lower than XP are sorely out of >luck; that doesn't mean that XP and beyond isn't. This piqued my curiosity. I've searched the lists and only seem to have a vague understanding of the problem. Would it be possible for you or someone else to create a small C(++) program which drives this? That is, the program is such that if someone makes it work under rxvt, then the problem is most definitely solved? -- Mohan Embar http://www.thisiscool.com/ http://www.animalsong.org/ |
From: Earnie B. <ea...@us...> - 2006-04-23 15:33:57
|
Quoting Mohan Embar <gnu...@th...>: > Hi Earnie, > >> FWIW I'm giving up on trying to fix the PTY issue at least for the next >> five years. If someone else wants to give a shot at it please feel >> free; the problem plagues Cygwin as well. If you do take a look at it >> I suggest you take a look at the newer console API functions and make >> it work for XP and above. Versions lower than XP are sorely out of >> luck; that doesn't mean that XP and beyond isn't. > > This piqued my curiosity. I've searched the lists and only seem > to have a vague understanding of the problem. Would it be possible > for you or someone else to create a small C(++) program which drives > this? That is, the program is such that if someone makes it work under > rxvt, then the problem is most definitely solved? > start rxvt -e /c/windows/system32/ftp.exe When the windows version of ftp I/O can be controlled by rxvt then the problem is resolved. Earnie Boyd http://shop.siebunlimited.com |
From: Mohan E. <gnu...@th...> - 2006-04-23 15:50:54
|
Hi Earnie, >>> FWIW I'm giving up on trying to fix the PTY issue at least for the next >>> five years. If someone else wants to give a shot at it please feel >>> free; the problem plagues Cygwin as well. If you do take a look at it... >> This piqued my curiosity. I've searched the lists and only seem >> to have a vague understanding of the problem. Would it be possible >> for you or someone else to create a small C(++) program which drives >> this? That is, the program is such that if someone makes it work under >> rxvt, then the problem is most definitely solved? >> > >start rxvt -e /c/windows/system32/ftp.exe > >When the windows version of ftp I/O can be controlled by rxvt then the >problem is resolved. I know this is OT for MSYS, but how is this duplicable under Cygwin? You said the problem plagues Cygwin too; when I type "ftp" at the rxvt prompt, is launches an XP command window whereas simply typing "ftp" under a Cygwin shell seems to behave okay. -- Mohan |
From: Earnie B. <ea...@us...> - 2006-04-23 16:11:05
|
Quoting Mohan Embar <gnu...@th...>: > Hi Earnie, > >>>> FWIW I'm giving up on trying to fix the PTY issue at least for the next >>>> five years. If someone else wants to give a shot at it please feel >>>> free; the problem plagues Cygwin as well. If you do take a look at it... > > >>> This piqued my curiosity. I've searched the lists and only seem >>> to have a vague understanding of the problem. Would it be possible >>> for you or someone else to create a small C(++) program which drives >>> this? That is, the program is such that if someone makes it work under >>> rxvt, then the problem is most definitely solved? >>> >> >> start rxvt -e /c/windows/system32/ftp.exe >> >> When the windows version of ftp I/O can be controlled by rxvt then the >> problem is resolved. > > I know this is OT for MSYS, but how is this duplicable under Cygwin? > You said the problem plagues Cygwin too; when I type "ftp" at the rxvt > prompt, is launches an XP command window whereas simply typing "ftp" under > a Cygwin shell seems to behave okay. > Did you launch the Cygwin version of ftp or the Windows version of ftp? You must launch the windows version of ftp as I specified in the example. Earnie Boyd http://shop.siebunlimited.com |
From: Mohan E. <aw...@th...> - 2006-04-23 16:23:16
|
Hi Earnie, >> I know this is OT for MSYS, but how is this duplicable under Cygwin? >> You said the problem plagues Cygwin too; when I type "ftp" at the rxvt >> prompt, is launches an XP command window whereas simply typing "ftp" under >> a Cygwin shell seems to behave okay. >> > >Did you launch the Cygwin version of ftp or the Windows version of ftp? >You must launch the windows version of ftp as I specified in the >example. Here's a scrape of a Cygwin session: ========================================= Mohan@d9300 ~ $ which ftp /cygdrive/c/WINDOWS/system32/ftp Mohan@d9300 ~ $ ftp ftp> open ftp.tu-chemnitz.de Connected to ftp.tu-chemnitz.de. 220 Welcome to TU Chemnitz FTP service (postel). User (ftp.tu-chemnitz.de:(none)): anonymous 331 Please specify the password. Password: 230 Login successful. ftp> ls 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. INDEX LIESMICH lost+found pub readme 226 Directory send OK. ftp: 42 bytes received in 0.00Seconds 42000.00Kbytes/sec. ftp> cd pub 250 Directory successfully changed. ftp> quit 221 Goodbye. Mohan@d9300 ~ $ ========================================= -- Mohan Embar http://www.thisiscool.com/ http://www.animalsong.org/ |
From: Keith M. <kei...@us...> - 2006-04-23 16:18:32
|
On Sunday 23 April 2006 4:50 pm, Mohan Embar wrote: > >start rxvt -e /c/windows/system32/ftp.exe > > > >When the windows version of ftp I/O can be controlled by rxvt then the > >problem is resolved. > > I know this is OT for MSYS, but how is this duplicable under Cygwin? > You said the problem plagues Cygwin too; when I type "ftp" at the rxvt > prompt, is launches an XP command window whereas simply typing "ftp" > under a Cygwin shell seems to behave okay. Two issues with this statement: 1) Earnie very explicitly referred to the *native* ftp client, which is shipped with Windoze itself. If you simply invoke `ftp', without specifying the full path into the system32 directory, then you are not running the appropriate binary for this test; this is equally true of Cygwin and MSYS, both of which provide their own implementations of ftp, and each of which is specially implemented, to work around the PTY issue which we would like to solve, when run in their respective environments. 2) When you type `ftp' in a Cygwin shell, are you actually running in an RXVT anyway? Every Cygwin installation I have ever performed, (and I admit it has been a few years since the last), has started its shell, by default, in a Win32 console; if I want RXVT, I have to explicitly `exec' it. OTOH, MSYS starts in an RXVT, by default; if you *don't* want RXVT, then you have to explicitly disable it. Neither MSYS nor Cygwin exhibits the PTY problem, when run in Win32 console mode; both can be troublesome, if RXVT is deployed. Regards, Keith. |
From: Mohan E. <gnu...@th...> - 2006-04-23 16:33:37
|
Hi Keith, >Two issues with this statement: > >1) Earnie very explicitly referred to the *native* ftp client, which is >shipped with Windoze itself.... I did invoke the native ftp client. The same result occurs if I type /cygdrive/c/WINDOWS/system32/ftp at the Cygwin shell. >2) When you type `ftp' in a Cygwin shell, are you actually running in an >RXVT anyway? Every Cygwin installation I have ever performed, (and I >admit it has been a few years since the last), has started its shell, by >default, in a Win32 console; if I want RXVT, I have to explicitly `exec' >it. OTOH, MSYS starts in an RXVT, by default; if you *don't* want RXVT, >then you have to explicitly disable it. I didn't realize Cygwin had an rxvt. This is all new to me. My Cygwin shell also runs in a Win32 console, which is why I was confused by the previous statements - probably due to my ignorance. I'm searching my \cygwin\bin folder for an rxvt.exe but I'm not seeing one. Okay - hold the phone. I went into Cygwin setup, installed rxvt, invoked it and tried to launch ftp. It just hangs. MSYS rxvt at least lets it launch in a separate console Window. -- Mohan Embar http://www.thisiscool.com/ http://www.animalsong.org/ |
From: Keith M. <kei...@us...> - 2006-04-23 16:54:44
|
On Sunday 23 April 2006 2:39 pm, Earnie Boyd wrote: > Developers, > > Especially Keith. Erhmm, why me, especially? > I've just uploaded the above file to correct an > issue with the 1.0.11 dll version that prevented libtool from correctly > creating the .exe file in the build directory. The file contained in > the tarball is named new-msys-1.0.dll and this needs to be copied to > your msys-1.0.dll. > >http://prdownloads.sf.net/mingw/msys-1.0.dll-SNAP-1.0.11-2006.04.23.tar.bz2?download Ok. Will have a look when I can find a few spare minutes at work; (if only, and I'll be tied up in a training course for most of next week) :-) Do note that I develop exclusively on GNU/Linux at home, so I'm not well equipped to participate in MSYS development. > The snap contains a modification to munge the ``prefix'' variable to a > windows path. I would like comment on this. I've never been particularly enamoured of this concept. IIRC, it was introduced to ensure that `configure' scripts would identify `prefix' as a native Win32 path; I favour a less invasive solution to that, namely specifying the appropriate default in config.site: ac_default_prefix=`cd /mingw; pwd -W` or ac_default_prefix=`cd /usr/local; pwd -W` according to personal preference, (mine being the latter). Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-04-24 11:13:43
|
Quoting Keith Marshall <kei...@us...>: > On Sunday 23 April 2006 2:39 pm, Earnie Boyd wrote: >> Developers, >> >> Especially Keith. > > Erhmm, why me, especially? > Because I know you're familiar with the issue with the 2004 snapshot that causes libtool not work properly. >> I've just uploaded the above file to correct an >> issue with the 1.0.11 dll version that prevented libtool from correctly >> creating the .exe file in the build directory. The file contained in >> the tarball is named new-msys-1.0.dll and this needs to be copied to >> your msys-1.0.dll. >> >> http://prdownloads.sf.net/mingw/msys-1.0.dll-SNAP-1.0.11-2006.04.23.tar.bz2?download > > Ok. Will have a look when I can find a few spare minutes at work; (if > only, and I'll be tied up in a training course for most of next week) :-) > Do note that I develop exclusively on GNU/Linux at home, so I'm not well > equipped to participate in MSYS development. > >> The snap contains a modification to munge the ``prefix'' variable to a >> windows path. I would like comment on this. > > I've never been particularly enamoured of this concept. IIRC, it was > introduced to ensure that `configure' scripts would identify `prefix' as > a native Win32 path; I favour a less invasive solution to that, namely > specifying the appropriate default in config.site: > > ac_default_prefix=`cd /mingw; pwd -W` > Which is why I wanted comment. Are their others who wish to comment? Should MSYS installation just deliver an /etc/config.site with the ac_default_prefix set instead? Earnie Boyd http://shop.siebunlimited.com |
From: Keith M. <kei...@us...> - 2006-04-24 21:45:50
|
On Monday 24 April 2006 12:13 pm, you wrote: > >> Developers, > >> > >> Especially Keith. > > > > Erhmm, why me, especially? > > Because I know you're familiar with the issue with the 2004 snapshot > that causes libtool not work properly. Huh? I've never used libtool, so not really. I know I've participated in some discussion with Ralf Wildenhues, but I wouldn't say I'm particularly familiar with the issues. Regards, Keith. |
From: Julien L. <ju...@fa...> - 2006-04-24 12:11:09
|
On 24/04/2006 13:13, Earnie Boyd wrote: > Quoting Keith Marshall <kei...@us...>: >> On Sunday 23 April 2006 2:39 pm, Earnie Boyd wrote: >>> Developers, >> >>> The snap contains a modification to munge the ``prefix'' variable to a >>> windows path. I would like comment on this. >> >> I've never been particularly enamoured of this concept. IIRC, it was >> introduced to ensure that `configure' scripts would identify `prefix' as >> a native Win32 path; I favour a less invasive solution to that, namely >> specifying the appropriate default in config.site: >> >> ac_default_prefix=`cd /mingw; pwd -W` >> > > Which is why I wanted comment. Are their others who wish to comment? > Should MSYS installation just deliver an /etc/config.site with the > ac_default_prefix set instead? I would prefer if ac_default_prefix was conditionally set depending on MSYSTEM such as `if [ x$MSYSTEM = xMINGW32 ] ; then cd /mingw && pwd -W; else echo -n /usr/local; fi' If it was not conditional, I fear people (including me) might install msys packages in the /mingw folder. Then again, I don't see why we need a 'pwd -W'; I never fell upon a configure script which required a windows path. Did I miss something in the conversation ? Julien |
From: Earnie B. <ea...@us...> - 2006-04-24 16:23:50
|
Quoting Julien Lecomte <ju...@fa...>: > On 24/04/2006 13:13, Earnie Boyd wrote: >> Quoting Keith Marshall <kei...@us...>: >>> On Sunday 23 April 2006 2:39 pm, Earnie Boyd wrote: >>>> Developers, >>> >>>> The snap contains a modification to munge the ``prefix'' variable to a >>>> windows path. I would like comment on this. >>> >>> I've never been particularly enamoured of this concept. IIRC, it was >>> introduced to ensure that `configure' scripts would identify `prefix' as >>> a native Win32 path; I favour a less invasive solution to that, namely >>> specifying the appropriate default in config.site: >>> >>> ac_default_prefix=`cd /mingw; pwd -W` >>> >> >> Which is why I wanted comment. Are their others who wish to >> comment? Should MSYS installation just deliver an /etc/config.site >> with the ac_default_prefix set instead? > > I would prefer if ac_default_prefix was conditionally set depending > on MSYSTEM such as > `if [ x$MSYSTEM = xMINGW32 ] ; then cd /mingw && pwd -W; else echo -n > /usr/local; fi' > *NOT* doable easily; so it won't be done. However, you do bring up a good point that causes be to doubt that setting /etc/config.site is a good suggestion. > If it was not conditional, I fear people (including me) might install > msys packages in the /mingw folder. > *NOT* an issue with 1.0.11. The condition no longer exists with 1.0.11 that requires /bin and /usr/bin be reserved for msys applications. FWIW I have my environment set so that /bin and /usr/bin contain the MSYS and MinGW client environment and the msysDVLPR toolset is in /msys. > Then again, I don't see why we need a 'pwd -W'; I never fell upon a > configure script which required a windows path. Did I miss something > in the conversation ? > Review the archives. It is advisable to use the windows absolute path as prefix because some applications use preprocessor variables to reference file paths. Earnie Boyd http://shop.siebunlimited.com |
From: Keith M. <kei...@us...> - 2006-04-24 18:25:23
|
On Monday 24 April 2006 5:23 pm, Earnie Boyd wrote: > >>>> The snap contains a modification to munge the ``prefix'' variable > >>>> to a windows path. I would like comment on this. > >>> > >>> I've never been particularly enamoured of this concept. IIRC, it > >>> was introduced to ensure that `configure' scripts would identify > >>> `prefix' as a native Win32 path; I favour a less invasive solution > >>> to that, namely specifying the appropriate default in config.site: > >>> > >>> ac_default_prefix=`cd /mingw; pwd -W` > >> > >> Which is why I wanted comment. Are their others who wish to > >> comment? Should MSYS installation just deliver an /etc/config.site > >> with the ac_default_prefix set instead? > > > > I would prefer if ac_default_prefix was conditionally set depending > > on MSYSTEM such as > > `if [ x$MSYSTEM = xMINGW32 ] ; then cd /mingw && pwd -W; else echo -n > > /usr/local; fi' > > *NOT* doable easily; so it won't be done. However, you do bring up a > good point that causes be to doubt that setting /etc/config.site is a > good suggestion. On the contrary, I believe that would be *very* easy to do; just insert case `uname -s` in MINGW*) ac_default_prefix=`cd /mingw; pwd -W` ;; esac in /usr/local/share/config.site, instead of the simple unconditional ac_default_prefix=`cd /mingw; pwd -W` and you *will* get Julien's desired effect; if the `uname -s' result doesn't match the MINGW32 system name, then the case statement will fall through, leaving `ac_default_prefix=/usr/local', because that's what `configure' sets as default anyway, *before* sourcing `config.site'. IMO, this mechanism is infinitely preferable to kludging the shell or the MSYS runtime; it is a standard feature, supported by all autoconf generated configure scripts, and it is readily customised to suit each individual user's preferences. BTW, it *isn't* `/etc/config.site'; autoconf generated configure scripts don't look there automatically, (they will, only *if* the user explicitly exports `CONFIG_SITE=/etc/config.site', but I *don't* advocate requiring the user to do this). Here's how `configure' decides which `config.site' files it *will* source: - If the user exports `CONFIG_SITE', then only those files explicitly defined therein, as a space separated list of absolute path names, will be sourced; all specified files which exist, and are readable, will be sourced, in the order specified. - Otherwise, if the user specifies a `--prefix=...' option, then the two files `$prefix/share/config.site' and `$prefix/etc/config.site', (where `$prefix' represents the *verbatim* value specified in `--prefix=...'), will be sourced in this order. - Finally, if *neither* of the two preceding conditions applies, then the files `/usr/local/share/config.site' and `/usr/local/etc/config.site' will be sourced, again, in this order. In all three of the above cases, if any of the appropriate `config.site' files do not exist, or are not readable, `configure' silently skips its attempt to source them. Regards, Keith. |