Menu
▾
▴
#2472 [bind] error - event parsing?
After installation of Tk8.5.3 (with Tcl8.5.3)
I get for several (all?) application the following
error on startup
fr
Application initialization failed: Can't find a usable tk.tcl in the following directories:
/usr/local/beta/lib/tcl8.5/tk8.5 /usr/local/beta/lib/tk8.5 /usr/local/lib/tk8.5 /usr/local/beta/library
/usr/local/beta/lib/tk8.5/tk.tcl: no event type or button # or keysym
no event type or button # or keysym
while executing
"bind Listbox <MouseWheel> {
%W yview scroll [expr {- (%D / 120) * 4}] units
}"
invoked from within
"if {[tk windowingsystem] eq "aqua"} {
bind Listbox <MouseWheel> {
%W yview scroll [expr {- (%D)}] units
}
bind Listbox <Option-Mou..."
(file "/usr/local/beta/lib/tk8.5/listbox.tcl" line 182)
invoked from within
"source /usr/local/beta/lib/tk8.5/listbox.tcl"
(in namespace eval "::" script line 1)
invoked from within
"namespace eval :: [list source [file join $::tk_library $file.tcl]]"
(procedure "SourceLibFile" line 2)
invoked from within
"SourceLibFile listbox"
(in namespace eval "::tk" script line 4)
invoked from within
"namespace eval ::tk {
SourceLibFile button
SourceLibFile entry
SourceLibFile listbox
SourceLibFile menu
SourceLibFile panedwindow
SourceLibFile ..."
invoked from within
"if {$::tk_library ne ""} {
proc ::tk::SourceLibFile {file} {
namespace eval :: [list source [file join $::tk_library $file.tcl]]
}
..."
(file "/usr/local/beta/lib/tk8.5/tk.tcl" line 404)
invoked from within
"source /usr/local/beta/lib/tk8.5/tk.tcl"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list source $file]"
This probably means that tk wasn't installed properly.
--------------------
I've tried gcc-4.3.1 and gcc-4.2.4 each with
-O3 and -O .
At the moment, Tcl8.5.3 (compiled with gcc-4.3.1 -O3)
together with my previous Tk8.5.2 (compiled with
gcc-4.2.4 -O3) works just fine.
I have a GenToo system, but install Tcl/Tk 8.5.x
separately with --prefix=/usr/local/beta
More info about my gentoo system:
emerge --info
Portage 2.2_rc1 (default/linux/x86/2008.0, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.25-gentoo-r4 i686)
=================================================================
System uname: Linux-2.6.25-gentoo-r4-i686-Intel-R-_Pentium-R-_III_CPU_family_1266MHz-with-glibc2.0
Timestamp of tree: Thu, 03 Jul 2008 16:45:02 +0000
ccache version 2.4 [disabled]
app-shells/bash: 3.2_p39
dev-java/java-config: 1.3.7, 2.1.6-r1
dev-lang/python: 2.5.2-r5
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache: 2.4-r7
sys-apps/baselayout: 2.0.0
sys-apps/openrc: 0.2.5
sys-apps/sandbox: 1.2.20_alpha2-r1
sys-devel/autoconf: 2.13, 2.62-r1
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1
sys-devel/binutils: 2.18-r2
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool: 2.2.4
virtual/os-headers: 2.6.25-r4
ACCEPT_KEYWORDS="x86 ~x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2 -march=i686 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="buildpkg distlocks parallel-fetch preserve-libs sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo "
LDFLAGS=""
LINGUAS="en de"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.informatik.RWTH-Aachen.de/gentoo-portage"
USE="X acl berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups dbus doc dri dvd fortran gcj gdbm gnome gpm gtk gtk2 hal iconv ipv6 isdnlog jpeg kde midi mudflap ncurses nls nptl nptlonly opengl openmp pam pcre pdf perl png pppd python qt readline reflection session spl sqlite sqlite3 ssl svg tcl tcpd tetex tiff tk truetype-fonts type1-fonts unicode x86 xorg xulrunner zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en de" USERLAND="GNU" VIDEO_CARDS="nv"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Logged In: YES
user_id=80530
Originator: NO
Error is reported at runtime, not a
flaw in building.
Logged In: YES
user_id=410366
Originator: NO
The following bug in gentoo shows that the problem is in an incompatible changes in xproto-7.0.13: http://bugs.gentoo.org/show_bug.cgi?id=225999 (or it's a Tk fault where it cannot survive a new event in X protocol?)
Logged In: YES
user_id=68433
Originator: NO
Cause of the problem: parts of Tk have a hardcoded assumption that the X11 protocol constant LASTEvent is #defined to be exactly 35 (== MappingNotify + 1). In particular: the 'flagArray' and 'eventMasks' static array initializers in tkBind.c resp. tkEvent.c; possibly others as well.
This has been a valid assumption (from 1991 up until very recently), but X.org xproto-7.0.13 added a new "GenericEvent" event type and incremented LASTEvent.
This problem affects all versions of Tk from 4.0 through 8.6a1, as well as any extensions that reference the Tk extension event types VirtualEvent, ActivateNotify, DeactivateNotify, and MouseWheelEvent.
Proposed short-term fix: replace all uses of the symbolic constant LASTEvent with MappingNotify+1. This should restore source-level compatibility with newer Xlib releases and preserve ABI compatibility for Tk extensions. Conflicts between Tk "VirtualEvent" events and X11 "GenericEvent" events should not be a problem -- Tk does not select for GenericEvents, so it should never receive any from the X server (@@@ need to confirm this).
Long-term fix needs further discussion.
Logged In: YES
user_id=79902
Originator: NO
Further examination indicates that it is not possible to prevent the delivery of GenericEvents to Tk without abandoning the use of all extensions (XIM being the one we need more than any other, alas). Now, if generic events had been structured as an extension, we wouldn't have been bitten. But they weren't so we were.
Principal concern: whether there are any extensions that use Tk's faked up MouseWheel, Activate and Deactivate event numbers directly (instead of using a binding table). If not, we can just fix Tk and everyone else will come along for the ride.
Logged In: YES
user_id=410366
Originator: NO
At least one extension uses VirtualEvent, ActivateNotify and DeactivateNotify. It's Tile extension.
Logged In: YES
user_id=410366
Originator: NO
Another extension which mentions ActivateNotify is BLT.
Logged In: YES
user_id=68433
Originator: NO
@dkf --
| Further examination indicates that it is not possible to prevent the
| delivery of GenericEvents to Tk without abandoning the use of all
| extensions (XIM being the one we need more than any other, alas)
Where do you see this happening? Tk does not, by itself, select for GenericEvents on any window that it creates, so it should not receive any AFAICT.
XIM does not, by itself, rely on GenericEvents either. (XInput might, but that's a different extension - it deals with multiple keyboard and pointing devices. Tk does not use XInput).
Logged In: YES
user_id=79902
Originator: NO
I've been googling around and it seems that the X.Org plan is to move all extensions over to using generic events (I don't remember which blog I read this on). Leaving aside whether this is a good plan of theirs, it does mean that we can't count on not getting GEs dropped on us (well, not unless we compile and link against old headers/libraries, which is what the strict ABI compat folks need to do anyway). Analyzing GAH's patch from the gentoo bug report, the problem (for now) is that we encode the fact that LASTEvent is 35 (it isn't any more) in the flagArray in tkBind.c. GAH's fix adds a another dummy entry, but I think it is neater to split the table into two; one for the X11 events and one for Tk's virtual events. (We'll also need to fix all the places that read from that array; thankfully it's file-local.) The fixes need backporting, probably back as far as 8.4 (do we support 8.3 any more at all?) but that should be easy as this part has been static for over a decade (since Win and Mac support was added I guess).
It is worth considering whether we should move Tk's synthetic events elsewhere entirely? ABI compat's bust anyway. If we change it so that Tk's synthetic events have a non-zero high byte, we'll be completely out of the way of all the events that X11 defines (which I think are byte-ranged I believe); we've got space, as the structure uses an int to hold the type field.
Patch against Tk CVS HEAD
Logged In: YES
user_id=68433
Originator: NO
File Added: tk-lastevent.patch
Logged In: YES
user_id=79902
Originator: NO
I'm not convinced that that's the right fix *unless* ABI compat is prioritized over the unholy mess that will result the first time a GenericEvent is dropped on our laps.
Bleah. "Why, X.Org, why?"
Logged In: NO
@dkf --
> I'm not convinced that that's the right fix *unless* ABI compat is
> prioritized over the unholy mess that will result the first time a
> GenericEvent is dropped on our laps.
Under what circumstances would a GenericEvent ever make its way into Tk's
event loop? I can't find any way that this would ever happen in any
existing release of Tk.
Improved patch vs Tk HEAD
Logged In: YES
user_id=79902
Originator: NO
With even more reading, it seems that GenericEvents should only get delivered if using an XCB-enabled Xlib. I think. If that's true (the facts are very thin on the ground it seems) *and* we're not built with one of these XCB Xlibs (don't know what's going on there) then the suggested patch will work. But I think the extended version of it I attach is better still.
1) It adds a reminder to fix this properly in Tk 9
2) It removes the assumption that MappingNotify and VirtualEvent are necessarily contiguous
3) It adds a Tcl_Panic if one of these things hits us for real (so we can figure out what to do when that happens)
File Added: genericevent.patch
Logged In: YES
user_id=1109417
Originator: NO
while attempting to test genericevent.patch for our distro, I found that tk would not build. It is failing at this point:
gcc -c -O2 -march=pentium4 -pipe -pipe -Wall -Wno-implicit-int -fPIC -I/usr/src/tk8.5.3/unix/../unix -I/usr/src/tk8.5.3/unix/../generic -I/usr/src/tk8.5.3/unix/../bitmaps -I/usr/src/tcl8.5.3/generic -I/usr/src/tcl8.5.3/unix -DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\" -DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tk\ 8.5\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_GETATTR_NP=1 -DGETATTRNP_NOT_DECLARED=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_SHLIB_EXT=\".so\" -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1 -DHAVE_TYPE_OFF64_T=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_PW_GECOS=1 -DHAVE_XSS=1 -DHAVE_LIBXFT=1 -DHAVE_XFT=1 -DTCL_NO_DEPRECATED -DUSE_TCL_STUBS /usr/src/tk8.5.3/unix/../unix/tkUnixEvent.c
/usr/src/tk8.5.3/unix/../unix/tkUnixEvent.c: In function 'TransferXEventsToTcl':
/usr/src/tk8.5.3/unix/../unix/tkUnixEvent.c:297: error: expected ')' before 'xgePtr'
/usr/src/tk8.5.3/unix/../unix/tkUnixEvent.c:294: warning: unused variable 'xgePtr'
make: *** [tkUnixEvent.o] Error 1
Building without any patch or with tk-lastevent.patch completes with no errors.
Logged In: YES
user_id=1580598
Originator: NO
Because it should be Tcl_Panic("Wild GenericEvent; panic! (extension=%d,evtype=%d)",xgePtr->extension, xgePtr->evtype);
The comma was missing with gcc-4.3.1.
Logged In: YES
user_id=68433
Originator: NO
Revised version of genericevent.patch (removed timebomb code, compiles without warnings) committed to HEAD, backported to core-8-5-branch.
Logged In: YES
user_id=68433
Originator: NO
Patch partially applied to core-8-4 branch (generic/tk.h changes only).
This is enough to make all branches compile and run against new libX11 headers; more future-proofing TBDL.