Hi everyone. I have a simple main.tcl file with a single line 'package require img::png'. My environment: Windows XP Home SP3, ActiveTcl 8.5.9.1, TclDevKit 5.2.1 I try to make a starpack out of this:
The log shows no issues, seems everything is Ok, all packages are found and their dependencies are resolved so the freshly baked testpng.exe appears as a result. But when I try to launch it I get the message box telling me:
couldn't load library "D:/test/testpng.exe/lib/P-win32-ix86/img__base1.4.0.4/tkimg1404.dll": No error while executing "load [file join {D:/test/testpng.exe/lib/P-win32-ix86/img__base1.4.0.4} tkimg1404.dll]" ("package ifneeded img::base 1.4.0.4" script) invoked from within "package require img::base 1.4-2"
I've noticed the very same thing happens when I try to use any standard package which comes as DLL. Tcl-only packages are loaded just fine. I've studied the docs, searched the internet and found nothing that would make clear what I'm doing wrong. The demos bundled with TclDevKit don't work either - I tried wrapping "Img Demo -- As Starpack" but it was unusable out of the box - it supposes all the files needed are located in %ActiveTclInstallDir%\demos\Img, but there was nothing here so I've had to redirect it to some folder inside teapot repository (I found all these files there) and then remove and rescan all package dependencies. After building the demo I got the exact same result as described above - inability to load DLL. Is there some obvious thing I'm missing? -- Best regards, Eugene
> Hi everyone. > I have a simple main.tcl file with a single line 'package require img::png'. > My environment: Windows XP Home SP3, ActiveTcl 8.5.9.1, TclDevKit 5.2.1 > I try to make a starpack out of this:
> The log shows no issues, seems everything is Ok, all packages are found and > their dependencies are resolved so the freshly baked testpng.exe appears as a > result. But when I try to launch it I get the message box telling me:
> couldn't load library > "D:/test/testpng.exe/lib/P-win32-ix86/img__base1.4.0.4/tkimg1404.dll": No error > while executing > "load [file join {D:/test/testpng.exe/lib/P-win32-ix86/img__base1.4.0.4} > tkimg1404.dll]" > ("package ifneeded img::base 1.4.0.4" script) > invoked from within > "package require img::base 1.4-2"
> I've noticed the very same thing happens when I try to use any standard package > which comes as DLL. Tcl-only packages are loaded just fine. I've studied the > docs, searched the internet and found nothing that would make clear what I'm > doing wrong. The demos bundled with TclDevKit don't work either - I tried > wrapping "Img Demo -- As Starpack" but it was unusable out of the box - it > supposes all the files needed are located in %ActiveTclInstallDir%\demos\Img, > but there was nothing here so I've had to redirect it to some folder inside > teapot repository (I found all these files there) and then remove and rescan all > package dependencies. After building the demo I got the exact same result as > described above - inability to load DLL. > Is there some obvious thing I'm missing?
No, there is no problem with DLLs, I use it all the time. I think that you need to also add the img::base package, allong with img::png.
> Hi everyone. > I have a simple main.tcl file with a single line 'package require img::png'. > My environment: Windows XP Home SP3, ActiveTcl 8.5.9.1, TclDevKit 5.2.1 > I try to make a starpack out of this:
> The log shows no issues, seems everything is Ok, all packages are found and > their dependencies are resolved so the freshly baked testpng.exe appears as a > result. But when I try to launch it I get the message box telling me:
> couldn't load library > "D:/test/testpng.exe/lib/P-win32-ix86/img__base1.4.0.4/tkimg1404.dll": No error > while executing > "load [file join {D:/test/testpng.exe/lib/P-win32-ix86/img__base1.4.0.4} > tkimg1404.dll]" > ("package ifneeded img::base 1.4.0.4" script) > invoked from within > "package require img::base 1.4-2"
> I've noticed the very same thing happens when I try to use any standard package > which comes as DLL. Tcl-only packages are loaded just fine. I've studied the > docs, searched the internet and found nothing that would make clear what I'm > doing wrong. The demos bundled with TclDevKit don't work either - I tried > wrapping "Img Demo -- As Starpack" but it was unusable out of the box - it > supposes all the files needed are located in %ActiveTclInstallDir%\demos\Img, > but there was nothing here so I've had to redirect it to some folder inside > teapot repository (I found all these files there) and then remove and rescan all > package dependencies. After building the demo I got the exact same result as > described above - inability to load DLL. > Is there some obvious thing I'm missing?
Yes the package index is not set up correctly for dealing with being in a starkit. The dll needs to be copied to a temporary location and loaded from there.
> No, there is no problem with DLLs, I use it all the time. > I think that you need to also add the img::base package, allong with > img::png.
I did add img::base package, though not explicitly. It's added as a resolved dependency because I've provided -follow command line switch to tclapp. And I can check that img::base package is added to the starpack, here's excerpt from the log file:
Wrapping ... ... P package Tk 8.5.9 win32-ix86 ... package img::base 1.4.0.4 win32-ix86 package img::png 1.4.0.4 win32-ix86 ... Issues... ... P Tk 8.5.9 win32-ix86 @ img::base 1.4.0.4 win32-ix86 @ R C:/ActiveState/Tcl/lib/teapot img::png 1.4.0.4 win32-ix86 @ R C:/ActiveState/Tcl/lib/teapot ... Wrapping package(s): img::png 1.4.0.4 (win32-ix86) Zip archive Unpacking Copying contents Cutting out the meta data Ok. img::base 1.4.0.4 (win32-ix86) Zip archive Unpacking Copying contents Cutting out the meta data Ok. ... Generated D:/temp/testbin.vfs/testbin.exe Done
Moreover, if I unwrap the starpack (tclkitsh sdk.kit unwrap testbin.exe) I can see all the included packages inside testbin.vfs\testbin.vfs\lib\P-win32-ix86 directory and img::base is there too, so I suppose it's not the culprit. Even if I change main.tcl to require a package without any dependencies (like sqlite3) the error is still the same. BTW, Georgios, do you use tclkit or tclapp for wrapping? Because it seems that tclkit doesn't have this problem - if I wrap my testbin.vfs with it there's no error, I'm experiencing failures only with tclapp.
>> No, there is no problem with DLLs, I use it all the time. >> I think that you need to also add the img::base package, allong with >> img::png.
> I did add img::base package, though not explicitly. It's added as a > resolved dependency because I've provided -follow command line switch to > tclapp. And I can check that img::base package is added to the starpack, > here's excerpt from the log file:
> Wrapping ... > ... > P package Tk 8.5.9 win32-ix86 ... > package img::base 1.4.0.4 win32-ix86 > package img::png 1.4.0.4 win32-ix86 > ... > Issues... > ... > P Tk 8.5.9 win32-ix86 @ > img::base 1.4.0.4 win32-ix86 @ R C:/ActiveState/Tcl/lib/teapot > img::png 1.4.0.4 win32-ix86 @ R C:/ActiveState/Tcl/lib/teapot > ... > Wrapping package(s): > img::png 1.4.0.4 (win32-ix86) > Zip archive > Unpacking > Copying contents > Cutting out the meta data > Ok. > img::base 1.4.0.4 (win32-ix86) > Zip archive > Unpacking > Copying contents > Cutting out the meta data > Ok. > ... > Generated D:/temp/testbin.vfs/testbin.exe > Done
> Moreover, if I unwrap the starpack (tclkitsh sdk.kit unwrap testbin.exe) > I can see all the included packages inside > testbin.vfs\testbin.vfs\lib\P-win32-ix86 directory and img::base is > there too, so I suppose it's not the culprit. Even if I change main.tcl > to require a package without any dependencies (like sqlite3) the error > is still the same. > BTW, Georgios, do you use tclkit or tclapp for wrapping? Because it > seems that tclkit doesn't have this problem - if I wrap my testbin.vfs > with it there's no error, I'm experiencing failures only with tclapp.
> Yes the package index is not set up correctly for dealing with being in a > starkit. The dll needs to be copied to a temporary location and loaded > from there.
Well, does it mean I have to manually write some custom package index files for every binary package I want to include in a starpack just to have them loaded seamlessly? Doesn't seem it's "making it easy to create, build and deploy applications" like TclDevKit overview states :) And I didn't find anything in TclDevKit tclapp manual that would give a hint about how to make these index files...
>> Yes the package index is not set up correctly for dealing with being >> in a starkit. The dll needs to be copied to a temporary location and >> loaded from there.
> Well, does it mean I have to manually write some custom package index > files for every binary package I want to include in a starpack just to > have them loaded seamlessly? Doesn't seem it's "making it easy to > create, build and deploy applications" like TclDevKit overview states :) > And I didn't find anything in TclDevKit tclapp manual that would give a > hint about how to make these index files...
Doesn't work for me :) I've just copied everything you specified and changed only the binary basekit path (I don’t have 8.6) - still the same error. Now I suspect the basekit I use is the main culprit, as I also tried to change it to tclkit runtime I got from http://code.google.com/p/tclkit/downloads/list and with it it finally works. Now I wonder what's it in standard ActiveTcl basekits which prevents loading binary package DLLs...
> Doesn't work for me :) I've just copied everything you specified and > changed > only the binary basekit path (I don’t have 8.6) - still the same error. Now > I suspect the basekit I use is the main culprit, as I also tried to change > it to tclkit runtime I got from > http://code.google.com/p/tclkit/downloads/list and with it it finally > works. > Now I wonder what's it in standard ActiveTcl basekits which prevents > loading > binary package DLLs...
Nothing. What is the version of TDK you are having? I have never used any other basekit than the ones from ActiveTcl, and I have never had a problem, except under OS X.
I think you should contact ActiveState and report your findings. They respond really fast...
> Στις 16/5/2011 13:15, ο/η Eugene Mindrov έγραψε:
> Nothing. What is the version of TDK you are having? > I have never used any other basekit than the ones from ActiveTcl, and I > have never had a problem, except under OS X.
> I think you should contact ActiveState and report your findings. They > respond really fast...
> George
That's mighty strange, because I'm using the latest TDK 5.2.1, just downloaded it yesterday to have a look, I don't suppose it can't load DLLs just because it is an evaluation version? On the second thought it's most definitely not the case as I'm now almost sure the root cause is in basekits I use and the standard ones from ActiveTcl 8.5.9.1 don't do the trick for some reason. I'll try to use the basekit from 8.6 just like you did.
> "Eugene Mindrov" <eugene.mind...@gmail.com> wrote in message > news:iqqvc7$kkm$1@dont-email.me... >> I'll try to use the basekit from 8.6 just like you did.
> I've tried to use base-tk-thread-8.6.0.0.294743.tm from teapot repo but it > didn't solve the problem.
As George said, report this as a bug to ActiveState.
> As George said, report this as a bug to ActiveState.
I created a topic on ActiveState community support forum here: http://community.activestate.com/node/6677 Not sure it's a good place for such kind of problems, afraid to create an actual bug report because I'm not even sure it's a bug as it seems no one suffers from it but me (means hard to reproduce it).
Well, a sudden thought crossed my mind, I made several tests and here's what I've found: If a starpack is built with an ActiveState basekit it behaves like this: * when launched from _administrative_ user account - voila! - everything works, i.e. binary package DLL is loaded Ok. * when launched from a _restricted_ user account - it can't load any binary package DLL included.
And it just so happens that I don't use an account with admin privileges for my daily work under Windows (been doing that for years actually), only on rare occasions launching some application with elevated privileges when it really needs admin rights to work correctly. What a trap! BTW, tclapp (and other TDK apps) doesn't work under restricted user either:
C:/ActiveState/TclDevKit/bin/tclapp.exe/main.tcl: The TclPro ByteCode Loader is not available or does not support the correct version -- couldn't load library "C:/ActiveState/TclDevKit/bin/tclapp.exe/shared/lib/P-win32-ix86/tbcload1.7 /tbcload17.dll": No error
But I've been blindly dismissing this fact, thinking it's by design. So I would launch tclapp with elevated privileges, build my starpack, which then wouldn't work under my account, unable to load a DLL, apparently for the very same reason as tclapp can't use its bytecode loader.
Georgios, I bet you were under account with admin rights when you tested your TDK today :) So, seems there IS some subtle difference between ActiveTcl basekits and those located at http://code.google.com/p/tclkit as the latter could load DLL even under restricted account.
>> As George said, report this as a bug to ActiveState.
> I created a topic on ActiveState community support forum here: > http://community.activestate.com/node/6677 > Not sure it's a good place for such kind of problems, afraid to create an > actual bug report because I'm not even sure it's a bug as it seems no one > suffers from it but me (means hard to reproduce it).
Based on your last post, this really seems like it should be report as a bug and not on the forum -- bugs are reported via the ActiveState support/bug tracking pages.
> Based on your last post, this really seems like it should be report as a bug > and not on the forum -- bugs are reported via the ActiveState support/bug > tracking pages.
I only have a single user in my system, so I cannot test. But you can test, I have placed the executable here: http://www.ellogon.org/~petasis/tcl/tclapp-out.exe You can try it, and report back the results.
I have used TDK 5.2.0 (I haven't upgraded to 5.2.1 yet).
> Well, a sudden thought crossed my mind, I made several tests and here's > what I've found: > If a starpack is built with an ActiveState basekit it behaves like this: > * when launched from _administrative_ user account - voila! - everything > works, i.e. binary package DLL is loaded Ok. > * when launched from a _restricted_ user account - it can't load any > binary package DLL included.
> And it just so happens that I don't use an account with admin privileges > for my daily work under Windows (been doing that for years actually), > only on rare occasions launching some application with elevated > privileges when it really needs admin rights to work correctly. What a > trap! > BTW, tclapp (and other TDK apps) doesn't work under restricted user either:
> C:/ActiveState/TclDevKit/bin/tclapp.exe/main.tcl: The TclPro ByteCode > Loader is not available or does not support the correct version -- > couldn't load library > "C:/ActiveState/TclDevKit/bin/tclapp.exe/shared/lib/P-win32-ix86/tbcload1.7 /tbcload17.dll": > No error
> But I've been blindly dismissing this fact, thinking it's by design. So > I would launch tclapp with elevated privileges, build my starpack, which > then wouldn't work under my account, unable to load a DLL, apparently > for the very same reason as tclapp can't use its bytecode loader.
> Georgios, I bet you were under account with admin rights when you tested > your TDK today :) > So, seems there IS some subtle difference between ActiveTcl basekits and > those located at http://code.google.com/p/tclkit as the latter could > load DLL even under restricted account.
> I only have a single user in my system, so I cannot test. > But you can test, I have placed the executable here: > http://www.ellogon.org/~petasis/tcl/tclapp-out.exe > You can try it, and report back the results.
> I have used TDK 5.2.0 (I haven't upgraded to 5.2.1 yet).
> Note that I have applied this fix to my system: > http://support.microsoft.com/kb/2264107 > (I have a suspicion that this may be involved in your problem)
Georgios, thanks for helping me, everything is as expected - the executable you provided fails under restricted account, unable to load tkimg1404.dll, and runs smoothy under admin account, showing a console with "1.4.0.4" output. Regarding the fix you mentioned - seems I don't have it installed anywhere, I checked it on three boxes I could lay my hands on - Win XP Home/Pro and Windows 7 (which are also all affected by the bug), although all of them are configured to autoinstall any critical update and are up to date as far as I can see. I decided not to install it manually as it doesn't seem to be a critical one, and besides, even if it does fix the problem, I can't consider it a solution as I'm sure the vast majority of users won't have it installed either and I need to have my starpack running on an arbitrary system with as less requirements and external dependencies as possible. Luckily I have a workaround using these basekits from Google Code :) -- Best regards, Eugene
> "Georgios Petasis"<peta...@iit.demokritos.gr> сообщил/сообщила в > новостях следующее: news:iqrv07$2u3r$1@news.ntua.gr >> I only have a single user in my system, so I cannot test. >> But you can test, I have placed the executable here: >> http://www.ellogon.org/~petasis/tcl/tclapp-out.exe >> You can try it, and report back the results.
>> I have used TDK 5.2.0 (I haven't upgraded to 5.2.1 yet).
>> Note that I have applied this fix to my system: >> http://support.microsoft.com/kb/2264107 >> (I have a suspicion that this may be involved in your problem)
> Georgios, thanks for helping me, everything is as expected - the executable you > provided fails under restricted account, unable to load tkimg1404.dll, and runs > smoothy under admin account, showing a console with "1.4.0.4" output. > Regarding the fix you mentioned - seems I don't have it installed anywhere, I > checked it on three boxes I could lay my hands on - Win XP Home/Pro and Windows > 7 (which are also all affected by the bug), although all of them are configured > to autoinstall any critical update and are up to date as far as I can see. I > decided not to install it manually as it doesn't seem to be a critical one, and > besides, even if it does fix the problem, I can't consider it a solution as I'm > sure the vast majority of users won't have it installed either and I need to > have my starpack running on an arbitrary system with as less requirements and > external dependencies as possible. Luckily I have a workaround using these > basekits from Google Code :)
Does the same happens if you try to wrap another package? If you wrap the snack2.2 package, does again the executable not run in restricted accounts? (The snack dll does not depend on msvcrt.dll)
I have users that run my application in restricted accounts, and I have got no complains, other than missing DLLs. Strange...
> Does the same happens if you try to wrap another package? > If you wrap the snack2.2 package, does again the executable not run in > restricted accounts? (The snack dll does not depend on msvcrt.dll)
> I have users that run my application in restricted accounts, and I have > got no complains, other than missing DLLs. Strange...
Yes, even if I wrap only snack package the behavior is still the same - ActiveTcl basekit fails to load it under my restricted account.
> "Georgios Petasis" <peta...@iit.demokritos.gr> wrote in message > news:4DD22D7C.4020507@iit.demokritos.gr... >> Does the same happens if you try to wrap another package? >> If you wrap the snack2.2 package, does again the executable not run in >> restricted accounts? (The snack dll does not depend on msvcrt.dll)
>> I have users that run my application in restricted accounts, and I >> have got no complains, other than missing DLLs. Strange...
> Yes, even if I wrap only snack package the behavior is still the same - > ActiveTcl basekit fails to load it under my restricted account.
Is your restricted account a normal account, or the guest account?
> Στις 17/5/2011 11:28, ο/η Eugene Mindrov έγραψε:
> Is your restricted account a normal account, or the guest account?
Another thought crossed my mind... I have a freshly installed Windows XP in my Virtual PC just for testing purposes, it's not plagued by any tweaks/software/whatnot and it has only two users - Admin and NonAdmin, guest is also disabled. I tried running the binary you provided on this virtual box and guess what - it works under both accounts! Now I'm flabbergasted - it must be something with my system, to be more precise - with ALL my systems. Some piece of software or some obscure settings, I don't know yet... Continuing diggin' though...
>> Is your restricted account a normal account, or the guest account?
> Another thought crossed my mind... I have a freshly installed Windows XP > in my Virtual PC just for testing purposes, it's not plagued by any > tweaks/software/whatnot and it has only two users - Admin and NonAdmin, > guest is also disabled. I tried running the binary you provided on this > virtual box and guess what - it works under both accounts! Now I'm > flabbergasted - it must be something with my system, to be more precise > - with ALL my systems. Some piece of software or some obscure settings, > I don't know yet... Continuing diggin' though...
I have just created a new user, and tested. It works in my pc:
I've finally found why it doesn't work for me. The main culprit is a little nifty program I use everywhere - SuRun, it basically helps working under restricted user (which I prefer to do over using admin account for my daily tasks). It integrates into the system deeply - installs a service and some hooks but I've never experienced any trouble using it and have never seen it conflict with any other software. Until now. So the issue can be solved by unloading SuRun from memory, after that there's no more complaints about inability to load DLLs from starpacks built with ActiveSatte basekits. One mystery still remains though - basekits hosted on Google Code are not suffering from SuRun in any way... Regardless, seems it's time for me to go close this bug I opened yesterday in ActiveState bugzilla :)
