From: SourceForge.net <no...@so...> - 2011-12-01 08:56:27
|
Bugs item #967195, was opened at 2004-06-05 10:37 Message generated for change (Comment added) made by nijtmans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=967195&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 27. Channel Types Group: obsolete: 8.5a2 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Kevin B KENNY (kennykb) Assigned to: Jan Nijtmans (nijtmans) Summary: Test failures on mingw build Initial Comment: Platform: Win2k Compiler: mingw gcc Configuration options: --enable-symbols --enable-threads With the above configuration, the following error occurs when running make TESTFLAGS='-singleproc 1' test. Without the '-singleproc 1' option, every test file fails with a verbose error message because of this bug. The test works correctly under 8.4 (tip of branch) or under VC++ - the problem is specific to mingw and 8.5. ==== winpipe-8.19 ensure parse_cmdline isn't doing wildcard replacement FAILED ==== Contents of test case: exec [interpreter] $path(echoArgs.tcl) foo * makefile.?c bar ---- Result was: {C:/Documents and Settings/kennykb/My Documents/SourceForge/tcl/NSK1KENNKEVI01-m ingw/echoArgs.tcl} {foo big cat32.exe cat32.o config.log config.status config.st atus.lineno echoArgs.tcl libtcl85g.a libtcldde13g.a libtclreg11g.a libtclstub85g .a little Makefile nothing regcomp.o regerror.o regexec.o regfree.o stderr stdou t strftime.o strtoll.o strtoull.o stub16.o tcl.hpj tcl.res.o tcl85g.dll tclAlloc .o tclAppInit.o tclAsync.o tclBasic.o tclBinary.o tclCkalloc.o tclClock.o tclCmd AH.o tclCmdIL.o tclCmdMZ.o tclCompCmds.o tclCompExpr.o tclCompile.o tclConfig.o tclConfig.sh tclDate.o tcldde13g.dll tclDictObj.o tclEncoding.o tclEnv.o tclEven t.o tclExecute.o tclFCmd.o tclFileName.o tclGet.o tclHash.o tclHistory.o tclInde xObj.o tclInterp.o tclIO.o tclIOCmd.o tclIOGT.o tclIOSock.o tclIOUtil.o tclLink. o tclListObj.o tclLiteral.o tclLoad.o tclMain.o tclNamesp.o tclNotify.o tclObj.o tclPanic.o tclParse.o tclParseExpr.o tclPathObj.o tclpip85g.dll tclPipe.o tclPk g.o tclPkgConfig.o tclPosixStr.o tclPreserve.o tclProc.o tclreg11g.dll tclRegexp .o tclResolve.o tclResult.o tclScan.o tclsh.res.o tclsh85g.exe tclStringObj.o tc lStubInit.o tclStubLib.o tcltest.exe tclTest.o tclTestObj.o tclTestProcBodyObj.o tclThread.o tclThreadAlloc.o tclThreadJoin.o tclThreadTest.o tclTimer.o tclTrac e.o tclUtf.o tclUtil.o tclVar.o tclWin32Dll.o tclWinChan.o tclWinConsole.o tclWi nDde.o tclWinError.o tclWinFCmd.o tclWinFile.o tclWinInit.o tclWinLoad.o tclWinN otify.o tclWinPipe.o tclWinReg.o tclWinSerial.o tclWinSock.o tclWinTest.o tclWin Thrd.o tclWinTime.o testMain.o makefile.?c bar} ---- Result should have been (exact matching): {C:/Documents and Settings/kennykb/My Documents/SourceForge/tcl/NSK1KENNKEVI01-m ingw/echoArgs.tcl} {foo * makefile.?c bar} ==== winpipe-8.19 FAILED ---------------------------------------------------------------------- >Comment By: Jan Nijtmans (nijtmans) Date: 2011-12-01 00:56 Message: The issue was not the length of the command line, but the fact that the command line contains '*' as one of the arguments. In an (incorrectly) built tclsh, this expands to multiple arguments, which screws up all Tcl tests, not only the ones testing command line arguments. My further ideas have nothing to do with tcltest, but at least this change allows me to concentrate on the real problem here. Further idea: backport handling of TCL_BROKEN_MAINARGS from Tcl 8.6 to 8.5 and 8.4, so the setargv() function is only used when necessary (i.e with cygwin and mingw32, but not mingw-w64). Final step: I would like to discuss on Tcl-Core removing support for mingw32 in Tcl 8.6: There is an alternative now (mingw-w64) which does a much better job, not only in command line handling but in much more areas. This means that the function setargv() finally can be removed completely. People ignoring this, still using mingw32, will have a few failing tests, like winpipe-8.19, but those rightfully point to bugs in mingw32. Regards, Jan Nijtmans ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2011-11-30 13:16 Message: I see this reduces the number of arguments passed to child processes in the -singleproc 0 mode. That seems fine. Is the length of the command line an issue here? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2011-11-30 13:12 Message: As the tcltest maintainer, I'd like to review patches. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2011-11-30 13:10 Message: Modified tcltest.tcl in all branches such that it no longer transfers default configuration arguments to its sub-processes. This is the simplest fix, to make at least tcltest work in all situations, no matter how tclsh/tcltest expands its arguments. It's an improvement which doesn't hurt: It only modifies the command line arguments used between the main tcltest process and its sub-processes, it's not visible outside. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2011-11-30 13:06 Message: Why does this bug involve changes to the tcltest package? ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2011-11-30 05:10 Message: Since a few years, mingw-w64 is available, which does the command line parsing correctly, So I would like to finally get rid of the setargv function: This should not be Tcl's responsibility. Working on that. ---------------------------------------------------------------------- Comment By: Kevin B KENNY (kennykb) Date: 2004-06-11 19:08 Message: Logged In: YES user_id=99768 mingw runtime still needs the old 'setargv' function that was removed back in February. I put it back, conditioned on #if defined( __GNUC__ ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=967195&group_id=10894 |