From: SourceForge.net <no...@so...> - 2012-04-26 13:01:32
|
Bugs item #3508771, was opened at 2012-03-19 08:35 Message generated for change (Comment added) made by nijtmans 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: Fixed 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: Jan Nijtmans (nijtmans) Date: 2012-04-26 06:01 Message: Thanks! This should be fixed now. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-04-26 05:54 Message: Tcl build is broken on unix on 8.5 and trunk. gcc -O2 -pipe -Wl,--export-dynamic tclAppInit.o -L/home/dgp/fossil/tcl8.5/unix -ltcl8.5 -ldl -lieee -lm \ -Wl,-rpath,/home/dgp/x86_64/linuxoldld/lib -o tclsh /home/dgp/fossil/tcl8.5/unix/libtcl8.5.a(tclStubInit.o):(.data.rel+0x8a8): undefined reference to `TclMacOSXGetFileAttribute' /home/dgp/fossil/tcl8.5/unix/libtcl8.5.a(tclStubInit.o):(.data.rel+0x8c0): undefined reference to `TclMacOSXMatchType' /home/dgp/fossil/tcl8.5/unix/libtcl8.5.a(tclStubInit.o):(.data.rel+0x8c8): undefined reference to `TclMacOSXNotifierAddRunLoopMode' collect2: ld returned 1 exit status NULLing out the undefined routines appears to be an effective fix, but I have no confidence poking around here without a lot more review. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-04-26 05:48 Message: Should be fixed now. > For future reference, adding stuff to (or rearranging!) a platform API when > you can't build and test on that platform is a good way to get into > trouble. Some things are *incredibly* finicky... Yes, I know. But I simply don't have access to OSX, so I don't know what to do about that, other than being very carefull. Apparently I am not carefull enough. The trouble comes from the fact that each platform has its own stub table which is organized differently. It would be much easier if there was only one stub table without that many modifications per platform, but it's not easy to change that. At least CYGWIN shows this pain, which I solved by combining the windows and UNIX stub tables into one. Making a separate table for CYGWIN would only compicate things more ;-( Anyway, I hope it works now, otherwise please let me know! ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-04-26 05:35 Message: Works with Tk 8.6 too, provided I comment out the current unix entries for the tkPlat interface in tk.decls and run 'make genstubs' first. That is, it's the same problem as is on the 8.5 branch and it should be simple to fix (compat functions that Tcl_Panic would be step 1...) For future reference, adding stuff to (or rearranging!) a platform API when you can't build and test on that platform is a good way to get into trouble. Some things are *incredibly* finicky... ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-04-26 05:19 Message: That fixed it for tk-cocoa-8-5-backport branch. Main Tk core-8-5-branch doesn't work currently; it's missing definitions for all those Win functions you've just added. :-) Not tested the 8.6 code yet; that's next... ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-04-26 03:47 Message: Should be fixed now. > Cygwin is not a supported That's what I'm trying to change, and I must say that it already is working quite well: 99% ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-04-26 03:40 Message: The simplest fix is to just roll the changes to tclInt.decls back and rebuild. After all, OSX is a supported platform that was broken by this, and Cygwin is not a supported platform (especially if trying to do a mixed build). ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-04-26 03:38 Message: OK, I'll have a look ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-04-26 03:36 Message: Context: https://core.tcl.tk/tcl/annotate?checkin=3caedf05df5f633f&filename=generic/tclStubInit.c There's a lot of churn in the OSX part, which is weird as OSX is definitely disjoint from Cygwin. (There's no reason for *ever* calling TclWinConvertError on OSX!) ---------------------------------------------------------------------- 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 |