From: Teemu N. <sti...@ya...> - 2010-10-03 10:46:21
|
Hello! I still haven't released Tcl etc. as I've run into problems: tclsh doesn't execute any scripts and I have confirmed this with Procmon. But if I execute tclsh with strace the script runs normally. Maybe this has something to do with Msys' handling of paths? I even tried Mumit Khan's old 8.3.4 package and it behaves exactly the same. Running tclsh with Cygwin works without problems. Teemu |
From: Earnie <ea...@us...> - 2010-10-05 12:21:21
|
Teemu Nätkinniemi wrote: > Hello! > > I still haven't released Tcl etc. as I've run into problems: tclsh > doesn't execute any scripts and I have confirmed this with Procmon. But > if I execute tclsh with strace the script runs normally. Maybe this has > something to do with Msys' handling of paths? I even tried Mumit Khan's > old 8.3.4 package and it behaves exactly the same. Running tclsh with > Cygwin works without problems. > Did you add __MSYS__ to all the places there is a __CYGWIN__ in the source? Earnie |
From: Teemu N. <sti...@ya...> - 2010-10-05 14:28:37
|
On 5.10.2010 15:21, Earnie wrote: > Did you add __MSYS__ to all the places there is a __CYGWIN__ in the source? Every single one of them. Although Msys' new GCC 3.4.4 defines CYGWIN and CYGWIN32 so it wouldn't matter that much. At first I noticed that new GCC uses -mno-msys instead of -mno-cygwin but fixing that didn't help either. |
From: Earnie <ea...@us...> - 2010-10-15 13:46:07
|
Teemu Nätkinniemi wrote: > On 5.10.2010 15:21, Earnie wrote: > >> Did you add __MSYS__ to all the places there is a __CYGWIN__ in the source? > > Every single one of them. Although Msys' new GCC 3.4.4 defines CYGWIN > and CYGWIN32 so it wouldn't matter that much. At first I noticed that > new GCC uses -mno-msys instead of -mno-cygwin but fixing that didn't > help either. > That could be a problem. Defining __CYGWIN__ and __CYGWIN32__ by default may cause a __MSYS__ package to fail because not everything should be considered the same as __CYGWIN__ since the newer __CYGWIN__ may provide for some logic not existing in __MSYS__. Earnie |
From: Charles W. <cwi...@us...> - 2010-10-15 15:53:04
|
On 10/15/2010 9:45 AM, Earnie wrote: > Teemu Nätkinniemi wrote: >> Although Msys' new GCC 3.4.4 defines CYGWIN >> and CYGWIN32 so it wouldn't matter that much. > > That could be a problem. Defining __CYGWIN__ and __CYGWIN32__ by > default may cause a __MSYS__ package to fail because not everything > should be considered the same as __CYGWIN__ since the newer __CYGWIN__ > may provide for some logic not existing in __MSYS__. True, but defining it is usually a better first approximation than NOT defining it. Then, you can change the source as: #if defined(__CYGWIN__) && !defined(__MSYS__) stuff that doesn't apply to msys #endif in just a FEW places, rather than #if defined(__CYGWIN__) || defined(__MSYS__) stuff that applies to both cygwin and msys #endif in a whole TON of places. -- Chuck |
From: Teemu N. <sti...@ya...> - 2010-10-15 18:09:08
|
>>> Although Msys' new GCC 3.4.4 defines CYGWIN >>> and CYGWIN32 so it wouldn't matter that much. >> >> That could be a problem. Defining __CYGWIN__ and __CYGWIN32__ by >> default may cause a __MSYS__ package to fail because not everything >> should be considered the same as __CYGWIN__ since the newer __CYGWIN__ >> may provide for some logic not existing in __MSYS__. > > True, but defining it is usually a better first approximation than NOT > defining it. Then, you can change the source as: > > #if defined(__CYGWIN__)&& !defined(__MSYS__) > stuff that doesn't apply to msys > #endif I've tried disabling things that are specific to Cygwin, for example path conversion which I think is the culprit here, but haven't had any luck so far. Teemu |
From: Charles W. <cwi...@us...> - 2010-10-15 18:11:04
|
On 10/15/2010 2:08 PM, Teemu Nätkinniemi wrote: > I've tried disabling things that are specific to Cygwin, for example > path conversion which I think is the culprit here, but haven't had any > luck so far. I know I promised to look in to your ports, but I haven't had time yet. It's still on my TODO list. -- Chuck |
From: Teemu N. <sti...@ya...> - 2011-04-26 07:53:59
|
On 15.10.2010 21:10, Charles Wilson wrote: > On 10/15/2010 2:08 PM, Teemu Nätkinniemi wrote: >> I've tried disabling things that are specific to Cygwin, for example >> path conversion which I think is the culprit here, but haven't had any >> luck so far. > > I know I promised to look in to your ports, but I haven't had time yet. > It's still on my TODO list. I decided to revisit the problem with TCL after MSYS 1.0.17 was released. I built gdb version 6.8 from Cygwin's sources and after running a simple Hello World I noticed that the scripts actually do work fine except the don't output anything to console but for some reason under gdb the output works as well. For example: (gdb) set args hello.tcl (gdb) run Starting program: /usr/bin/tclsh84.exe hello.tcl [New thread 3812.0x4c4] Error: dll starting at 0x770b0000 not found. Error: dll starting at 0x75500000 not found. Error: dll starting at 0x770b0000 not found. Error: dll starting at 0x77530000 not found. [New thread 3812.0xf0c] [New thread 3812.0xab0] [New thread 3812.0xfb0] [New thread 3812.0x8e0] [New thread 3812.0xdc8] [New thread 3812.0x708] Hello, World ! Program exited normally. Teemu |
From: Earnie <ea...@us...> - 2011-04-26 15:28:37
|
Teemu Nätkinniemi wrote: > > I built gdb version 6.8 from Cygwin's sources and after running a simple > Hello World I noticed that the scripts actually do work fine except the > don't output anything to console but for some reason under gdb the > output works as well. > Let me guess, you're using RXVT. If so, then don't! See the lists archives and the wiki to find out more about broken pty emulation. Earnie |
From: Charles W. <cwi...@us...> - 2011-04-26 16:05:24
|
On 4/26/2011 11:28 AM, Earnie wrote: >> I built gdb version 6.8 from Cygwin's sources and after running a simple >> Hello World I noticed that the scripts actually do work fine except the >> don't output anything to console but for some reason under gdb the >> output works as well. >> > > Let me guess, you're using RXVT. If so, then don't! See the lists > archives and the wiki to find out more about broken pty emulation. I'd recommend using mingw-get to install 'msys-console' and then run 'console-config'. This will install and configure Console2 (console.sf.net) for use with MSys and MinGW -- and Console2 does not suffer from the "pty problem" that rxvt and mintty do. With regards to the TCL/TK issue, once I get the new msys-perl released [coming soon], I'm going to take a closer look at Teemu's and LRN's tcltk packages, with an eye toward releasing an official set of msys- AND mingw- versions of them. THEN, the mingw- versions can be used to support an updated build of (mingw)-gdb/insight [*], and the msys- versions can be used to support git (tcltk is one of the long list of dependencies needed for a complete port of git to msys). [*] the most recent releases of gdb/insight support using a pre-installed tcl/tk, rather than rolling its own (out of date) build internally. -- Chuck |
From: Teemu N. <sti...@ya...> - 2011-04-26 16:46:13
|
On 26.4.2011 19:05, Charles Wilson wrote: > On 4/26/2011 11:28 AM, Earnie wrote: >>> I built gdb version 6.8 from Cygwin's sources and after running a simple >>> Hello World I noticed that the scripts actually do work fine except the >>> don't output anything to console but for some reason under gdb the >>> output works as well. >>> >> >> Let me guess, you're using RXVT. If so, then don't! See the lists >> archives and the wiki to find out more about broken pty emulation. > > I'd recommend using mingw-get to install 'msys-console' and then run > 'console-config'. This will install and configure Console2 > (console.sf.net) for use with MSys and MinGW -- and Console2 does not > suffer from the "pty problem" that rxvt and mintty do. Doesn't work with Console2 or mintty. By the way, is there a way to use MSYS developer mode with Console2? Teemu |
From: Charles W. <cwi...@us...> - 2011-04-26 17:54:17
|
On 4/26/2011 12:45 PM, Teemu Nätkinniemi wrote: > On 26.4.2011 19:05, Charles Wilson wrote: >> On 4/26/2011 11:28 AM, Earnie wrote: >>>> I built gdb version 6.8 from Cygwin's sources and after running a simple >>>> Hello World I noticed that the scripts actually do work fine except the >>>> don't output anything to console but for some reason under gdb the >>>> output works as well. >>>> >>> >>> Let me guess, you're using RXVT. If so, then don't! See the lists >>> archives and the wiki to find out more about broken pty emulation. >> >> I'd recommend using mingw-get to install 'msys-console' and then run >> 'console-config'. This will install and configure Console2 >> (console.sf.net) for use with MSys and MinGW -- and Console2 does not >> suffer from the "pty problem" that rxvt and mintty do. > > Doesn't work with Console2 That's interesting. > or mintty. But this is expected. mintty uses pty's to communicate with the inferior, just like rxvt does. > By the way, is there a way to use > MSYS developer mode with Console2? Yes: my /usr/lib/Console2/console.xml has this <tab/> element: <tab title="MSysDvlpr" icon="C:\MinGW\msys\1.0\m.ico"> <console shell="C:\MinGW\msys\1.0\bin\sh.exe -c 'MSYSTEM=MSYS exec /bin/sh --login -i'" init_dir="C:\MinGW\msys\1.0\bin"/> <cursor style="8" r="255" g="0" b="128"/> <background type="0" r="255" g="255" b="208"> <image file="" relative="0" extend="0" position="0"> <tint opacity="0" r="0" g="0" b="0"/> </image> </background> </tab> So you can either launch console as: C:\MinGW\msys\1.0\lib\Console2\Console.exe -t MSysDvlpr or, once you've launched console using the "normal" shortcut, just press CTRL-F2 to open a new tab using that <tab/> element descriptor (because the MSysDvlpr descriptor is the second one in the console.xml file). -- Chuck |
From: Charles W. <cwi...@us...> - 2010-10-05 15:19:33
|
On 10/3/2010 6:46 AM, Teemu Nätkinniemi wrote: > I still haven't released Tcl etc. as I've run into problems: tclsh > doesn't execute any scripts and I have confirmed this with Procmon. But > if I execute tclsh with strace the script runs normally. Maybe this has > something to do with Msys' handling of paths? I even tried Mumit Khan's > old 8.3.4 package and it behaves exactly the same. Running tclsh with > Cygwin works without problems. Teemu -- send me a private message with a link to your tcltk stuff, and I'll give it some testing next weekend. I've built several versions of tcl/tk on cygwin over the years (I use a private version in my cygwin installation instead of their ancient "official" one). -- Chuck |