Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Upating Tcl/Tk installation breaks Tkx?

50 views
Skip to first unread message

Kevin Walzer

unread,
Apr 11, 2013, 10:59:28 PM4/11/13
to tc...@perl.org
I have recently done a minor version rev of my Tk installation (from
8.5.12 to 8.5.13) and now I can't run my Perl Tkx script. It fails with
this error message:

Kevin-Walzers-MacBook-5:stringdrill-2 kevin$ macperl stringdrill.pl
attempt to provide package Tk 8.5.12 failed: package Tk 8.5.13 provided
instead at stringdrill.pl line 3.

How can I solve this problem? It doesn't appear that
rebuilding/reinstalling Tkx is necessary as cpan tells me my
installation is up-to-date. Is there a way to specify the required
version of Tk in my Perl script?

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

Jeff Hobbs

unread,
Apr 16, 2013, 11:01:29 PM4/16/13
to k...@codebykevin.com, tc...@perl.org
On Thu, Apr 11, 2013 at 7:59 PM, Kevin Walzer <k...@codebykevin.com> wrote:
> I have recently done a minor version rev of my Tk installation (from 8.5.12
> to 8.5.13) and now I can't run my Perl Tkx script. It fails with this error
> message:
>
> Kevin-Walzers-MacBook-5:stringdrill-2 kevin$ macperl stringdrill.pl
> attempt to provide package Tk 8.5.12 failed: package Tk 8.5.13 provided
> instead at stringdrill.pl line 3.
>
> How can I solve this problem? It doesn't appear that rebuilding/reinstalling
> Tkx is necessary as cpan tells me my installation is up-to-date. Is there a
> way to specify the required version of Tk in my Perl script?

Can you force a rebuild anyway? I wonder if something in the Tcl.xs
underlying library has the 8.5.12 embedded that is causing the
conflict.

Jeff

Kevin Walzer

unread,
Apr 17, 2013, 8:33:44 PM4/17/13
to Jeff Hobbs, tc...@perl.org
On 4/16/13 11:01 PM, Jeff Hobbs wrote:
> Can you force a rebuild anyway? I wonder if something in the Tcl.xs
> underlying library has the 8.5.12 embedded that is causing the
> conflict.

How would I do that? I'm not very familiar with Perl's package
internals, so it's not clear to me how to delete a package and/or
rebuild it--cpan doesn't seem to support this.

Another question, though, is more general: I had a build of Tcl/Tk 8.6
elsewhere on my path and Tkx picked that up without crashing; but when I
deleted that, it found Tk 8.5.13 and crashed. Why is this? This is a
concern because I was hoping to deploy an app on the Mac that linked to
whatever version of Tcl/Tk was installed by the system (bundling a tkkit
won't work because of Mac App Store rules), and it needs to be reliable.

--Kevin

Jeff Hobbs

unread,
Apr 17, 2013, 8:43:52 PM4/17/13
to k...@codebykevin.com, tc...@perl.org
On Wed, Apr 17, 2013 at 5:33 PM, Kevin Walzer <k...@codebykevin.com> wrote:
> On 4/16/13 11:01 PM, Jeff Hobbs wrote:
>>
>> Can you force a rebuild anyway? I wonder if something in the Tcl.xs
>> underlying library has the 8.5.12 embedded that is causing the
>> conflict.
>
>
> How would I do that? I'm not very familiar with Perl's package internals, so
> it's not clear to me how to delete a package and/or rebuild it--cpan doesn't
> seem to support this.

That I'm not sure on ... I just use ppm.

> Another question, though, is more general: I had a build of Tcl/Tk 8.6
> elsewhere on my path and Tkx picked that up without crashing; but when I
> deleted that, it found Tk 8.5.13 and crashed. Why is this? This is a concern
> because I was hoping to deploy an app on the Mac that linked to whatever
> version of Tcl/Tk was installed by the system (bundling a tkkit won't work
> because of Mac App Store rules), and it needs to be reliable.

You can control the Tcl used via PERL_TCL_DLL or PERL_TCL_DL_PATH env
(or Tcl::DL_PATH in Tcl.pm), but otherwise it should just pull it off
the path.

You can see the code at http://cpansearch.perl.org/src/VKON/Tcl-1.02/,
and the Tcl.xs file has a special load function for APPLE that will
try and load from Tcl.framework dirs. Also, the way it's hard-coded,
it tries to load 8.4 first, and if that fails, it counts down the
minor from 9 (8.9, 8.8, 8.7 ...).

Jeff

Kevin Walzer

unread,
Jul 3, 2013, 12:18:43 PM7/3/13
to tc...@perl.org
Hi,

On 4/17/13 8:43 PM, Jeff Hobbs wrote:
> On Wed, Apr 17, 2013 at 5:33 PM, Kevin Walzer <k...@codebykevin.com> wrote:
>> On 4/16/13 11:01 PM, Jeff Hobbs wrote:
>>>
>>> Can you force a rebuild anyway? I wonder if something in the Tcl.xs
>>> underlying library has the 8.5.12 embedded that is causing the
>>> conflict.

Just as a refresher, I am back to wrangling with Tkx breaking after a
minor version upgrade of my Tcl installation (from 8.5.12 to 8.5.13).
The behavior is similar to trying to load a Tcl package with the
"-exact" flag: i.e. package require -exact 1.0.3.

Is there anywhere I can file a bug on this? I have dug into the muck of
my Perl installation looking for a hard-coded version string '8.5.12,'
and I can't find this anywhere. The only place I can think it might be
is in the compiled C module that links Perl to Tcl.

Rebuilding isn't really an option as my hope is to deploy a standalone
app that can link to any 8.5.x of Tcl, which is installed by default on
recent versions of the Mac OS. That shouldn't be a tall order; Python's
Tkinter module handles this gracefully.

Thanks,

Kevin Walzer

unread,
Jul 3, 2013, 1:07:27 PM7/3/13
to tc...@perl.org
On 7/3/13 12:18 PM, Kevin Walzer wrote:
>
> Is there anywhere I can file a bug on this? I have dug into the muck of
> my Perl installation looking for a hard-coded version string '8.5.12,'
> and I can't find this anywhere. The only place I can think it might be
> is in the compiled C module that links Perl to Tcl.

I found a bug-report e-mail address at the Tkx Cpan page, and contacted
the maintainer there. We'll see what he/she reports. There are a few old
bugs listed online (2+ years) without any response, so I'm not going to
hold my breath.

--Kevin

Konovalov, Vadim (Vadim)** CTR **

unread,
Jul 3, 2013, 4:42:25 PM7/3/13
to k...@codebykevin.com, tc...@perl.org
> From: Kevin Walzer

> On 7/3/13 12:18 PM, Kevin Walzer wrote:
> >
> > Is there anywhere I can file a bug on this? I have dug
> into the muck of
> > my Perl installation looking for a hard-coded version
> string '8.5.12,'
> > and I can't find this anywhere. The only place I can think
> it might be
> > is in the compiled C module that links Perl to Tcl.


When you recieved the message from Jeff in April, was it any
helpful??


> I found a bug-report e-mail address at the Tkx Cpan page, and
> contacted
> the maintainer there. We'll see what he/she reports. There
> are a few old
> bugs listed online (2+ years) without any response, so I'm
> not going to
> hold my breath.

was it Tkx cpan module, or - as you said " C module that links Perl to Tcl"
?

these are 2 different modules.


and please keep us informed on your breathe practices, we're
holding our breaths...

Kevin Walzer

unread,
Jul 3, 2013, 4:58:55 PM7/3/13
to tc...@perl.org
On 7/3/13 4:42 PM, Konovalov, Vadim (Vadim)** CTR ** wrote:
>
> When you recieved the message from Jeff in April, was it any
> helpful??

I tried to follow his suggestion and force a rebuild, but I got lost on
how to proceed. There doesn't seem to be any mechanism in Perl to delete
and rebuild a module.

But as I said, that's not a solution in any case--I want to deploy my
app across multiple version of OS X that may have Tcl 8.5.9, 8.5.11 and
who knows what else installed. I find it hard to believe that Tkx (or
the underlying Tcl module) is so brittle that it can't load any version
of Tcl other than the exact one it was compiled against.

>
> was it Tkx cpan module, or - as you said " C module that links Perl to Tcl"
> ?
>
> these are 2 different modules.
>

Hmm. I thought it was Tkx returning the error, but it wasn't 100% clear.
Do you have another suggestion as to where I should file a bug?

Kevin Walzer

unread,
Jul 3, 2013, 6:24:16 PM7/3/13
to tc...@perl.org
On 7/3/13 4:58 PM, Kevin Walzer wrote:
> On 7/3/13 4:42 PM, Konovalov, Vadim (Vadim)** CTR ** wrote:

> Hmm. I thought it was Tkx returning the error, but it wasn't 100% clear.
> Do you have another suggestion as to where I should file a bug?


I think I've found the issue: a misconfigured pkgIndex.tcl in my Tk
installation that identifies the version as 8.5.12. Changing this to
8.5.13 alleviates the problem, and my Tkx sample app now runs.

I ran across the suggested fix here:

http://coding.derkeiler.com/Archive/Tcl/comp.lang.tcl/2008-12/msg00198.html

This is not surprising: as I do a lot of Tk core development, my working
installation of Tk is often not 100% "clean" but instead is rebuilt
piecemeal from incremental changes that I make and patches I commit. I
suspect a clean, fresh build of Tk would not display these issues.

What's especially curious is that my Tcl/Tk scripts don't show this
issue! No wonder I couldn't figure it out. Perhaps it has something to
do with the fact that I run my Tcl/Tk scripts from the Wish application
rather than the Tcl interpreter with a "package require Tk" invocation.

Anyway, sorry for the noise, but I thought it would be especially
helpful to get this fix documented for posterity: I've seen a few other
reports of the behavior in scattered forums and no other fix has ever
been proposed. What's the big relief for me is that I can proceed with
some Perl/Tkx apps in a production context.

Thanks to all,

Jeff Hobbs

unread,
Jul 4, 2013, 1:38:18 AM7/4/13
to k...@codebykevin.com, tc...@perl.org
On 2013-07-03, at 3:24 PM, Kevin Walzer <k...@codebykevin.com> wrote:
> On 7/3/13 4:58 PM, Kevin Walzer wrote:
>> On 7/3/13 4:42 PM, Konovalov, Vadim (Vadim)** CTR ** wrote:
>
>> Hmm. I thought it was Tkx returning the error, but it wasn't 100% clear.
>> Do you have another suggestion as to where I should file a bug?
>
>
> I think I've found the issue: a misconfigured pkgIndex.tcl in my Tk installation that identifies the version as 8.5.12. Changing this to 8.5.13 alleviates the problem, and my Tkx sample app now runs.

This makes sense that you can still have a Tk runtime library that is inconsistent with the library when building with so many environments around.

I just wanted to restart that Perl/Tkx leverages exclusively Tcl at the C level, and then requires that the Tk library be dynamically available (and self-consistent) that can be loaded in.

In ActivePerl, we wrap this into a single stardll (starkit-as-dll), but that's just for encapsulation purposes.

Jeff
0 new messages