From: SourceForge.net <no...@so...> - 2012-04-26 00:57:03
|
Bugs item #3508771, was opened at 2012-03-19 08:35 Message generated for change (Comment added) made by wordtech You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3508771&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: 52. Portability Support Group: current: 8.5.11 Status: Open >Resolution: None >Priority: 9 Private: No Submitted By: Jan Nijtmans (nijtmans) Assigned to: Jan Nijtmans (nijtmans) Summary: load tclreg.dll in cygwin tclsh Initial Comment: Using the stubs mechanism, it should be possible to load tclreg.dll (compiled with mingw or vc++) in a tclsh compiled with cygwin. I tried it, and it almost works, but not quite..... tclreg.dll calls the function TclWinGetPlatformId(), inits init function: if (TclWinGetPlatformId() == VER_PLATFORM_WIN32_NT) { regWinProcs = &unicodeProcs; } else { regWinProcs = &asciiProcs; } which resides in slot 9 of tclIntPlatStubs. But cygwin uses the UNIX stubs, which has TclpCreateTempFile() in slot 9. So, everything seems to work, but in fact a temporary file is created, and a handle to it is returned. This handle is != VER_PLATFORM_WIN32_NT, so this instructs tclreg.dll to use the ASCII variants of the registry functions. Solution: move TclpCreateTempFile from slot 9 to slot 22, and put TclWinGetPlatformId in slot 9. On UNIX, TclWinGetPlatformId does not exist, so use some #define to map it back to TclpCreateTempFile on non-cygwin. The same potential problem exists with the functions Tcl_WinUtfToTChar and Tcl_WinTCharToUtf, which are in the public API. TclWinGetPlatformId is not public, but because it is used in tclreg.dll I would like to make an exception for that. ---------------------------------------------------------------------- >Comment By: Kevin Walzer (wordtech) Date: 2012-04-25 17:57 Message: Bumping the priority of this bug to 9 and changing resolution to "none" because the recent changes to tclStubInit.c cause a segfault on Wish on OS X from trunk, and (according to dkf) on 8.5 as well. Wish segfaults on startup when trying to run TclMacOSXNotifierAddRunLoopMode in the notifier. I've confirmed that the changes in this bug report are the culprit because when I back them out of tclStubInit.c and revert it to its 2011 version, Wish starts up fine. I'm reluctant to patch tclStubInit.c because the changes are so extensive and I don't fully understand them, and I don't want to undo all the work you've put in here--but PLEASE take another look and ensure that these changes don't crash Wish on OS X. I will be glad to test any changes you make. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-04-25 06:33 Message: For Tcl, all win32 stub functions are implemented now for cygwin. Doing the same for the most important ones for Tk now (in the bug-3508771) branch ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-03-22 03:19 Message: Trunk compiles fine now. Thanks ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-03-22 03:05 Message: Unfortunately, Cygwin is UNIX, but it must have some Windows API's as well in order to be able to load win32 extensions. So, yes, TclWinGetPlatformId is appropriate. Cygwin is the only platform where this is actually implemented, for all other platforms the stub entry for TclpCreateTempFile is in this slot. Should be fixed now. Thanks! ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-03-22 02:39 Message: OK, having a look. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-03-22 02:26 Message: Note that this BROKE THE OSX BUILD on all the primary branches. Bumping prio until either this is rolled back (/shuffled off onto side branch) or fixed so that in appropriate leakage between platform-specific APIs no longer happens. (The name of the symbol is also inappropriate for a Unix API.) Undefined symbols: "_TclWinGetPlatformId", referenced from: _tclIntPlatStubs in tclStubInit.o ld: symbol(s) not found ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-03-20 03:54 Message: Implementation for TclWinGetPlatformId, Tcl_WinUtfToTChar and Tcl_WinTCharToUtf done and committed to core-8-4-branch, core-8-5-branch and trunk. (Since cygwin now switched to tcl 8.5, it would not have been necessary to do it for Tcl 8.4, but it worked, so why not....) Added a dummy TclWinCPUID too, because this function is in slot 29, the last win32 slot. win32 has more slots than unix, and this way all unused slots will be set to NULL in stead of some random value. And... TclWinCPUID is intel-specific, not Windows-specific: it can be implemented on UNIX and cygwin as well, the only requirement is that it has an Intel (or AMD) processor. The default implementation simply returns TCL_ERROR. The functions Tcl_WinUtfToTChar and Tcl_WinTCharToUtf had the problem that MAC_OSX has all UNIX functions as well, plus its own. Adding UNIX stub entries would mean that the two functions Tcl_MacOSXOpenBundleResources and Tcl_MacOSXOpenVersionedBundleResources would shift up!! So I used the trick to put the two new functions in the place of the max functions. Tricky, but it works. So the Tcl_MacOSXOpenBundleResources stub entry has its own function on OSX, it contains the function Tcl_WinUtfToTChar on cygwin, and it has NULL for other UNIXes. This makes the function Tcl_WinUtfToTChar effectively hidden from Cygwin, but - hey - that's exactly what we want because it should only be callable by win32 extensions. Keeping open, because tclInt.decls contains more functions that could be called by win32 extensions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3508771&group_id=10894 |