Is it possible to have binary packages wrapped with TclApp?
Eugene
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:
tclapp -prefix D:/ActiveState/Tcl/bin/base-tk8.5-thread-win32-ix86.exe ^
-nocompress -out testpng -verbose -architecture win32-ix86 ^
-log build.log -follow -pkgref img::png D:/test/main.tcl
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
Georgios Petasis
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.
George
Gerald W. Lester
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.
--
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+------------------------------------------------------------------------+
Eugene Mindrov
news:4DD033AD...@iit.demokritos.gr...
> 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.
Georgios Petasis
catch {console show}
puts [package require img::png]
With the following command:
C:\TclApps\TclDevKit\bin\tclapp.exe -- -prefix
"C:\TclApps\Tcl\bin\base-tk8.6-thread-win32-ix86.exe" -pkgref img::base
-pkgref img::png -pkgref pngtcl -pkgref zlibtcl test.tcl
works for me.
George
Eugene Mindrov
news:fwWzp.6352$Wp3....@news.usenetserver.com...
> 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...
Georgios Petasis
No. TclApp does that for you automatically.
George
Eugene Mindrov
> Wrapping the following code:
>
> catch {console show}
> puts [package require img::png]
>
> With the following command:
>
> C:\TclApps\TclDevKit\bin\tclapp.exe -- -prefix
> "C:\TclApps\Tcl\bin\base-tk8.6-thread-win32-ix86.exe" -pkgref
> img::base -pkgref img::png -pkgref pngtcl -pkgref zlibtcl test.tcl
>
> works for me.
>
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...
Georgios Petasis
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
Eugene Mindrov
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
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.
Gerald W. Lester
As George said, report this as a bug to ActiveState.
Eugene Mindrov
>
> 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).
Eugene Mindrov
> Wrapping the following code:
>
> catch {console show}
> puts [package require img::png]
>
> With the following command:
>
> C:\TclApps\TclDevKit\bin\tclapp.exe -- -prefix
> "C:\TclApps\Tcl\bin\base-tk8.6-thread-win32-ix86.exe" -pkgref
> img::base -pkgref img::png -pkgref pngtcl -pkgref zlibtcl test.tcl
>
> works for me.
>
> George
>
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.
Gerald W. Lester
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.
Eugene
новостях следующее: news:hpcAp.9704$Wp3....@news.usenetserver.com...
> 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.
>
be viewed here: http://bugs.activestate.com/show_bug.cgi?id=90071
Georgios Petasis
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)
George
Eugene
новостях следующее: 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 :)
--
Best regards,
Eugene
Georgios Petasis
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...
George
Eugene Mindrov
> 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.
--
Best regards,
Eugene
Georgios Petasis
Is your restricted account a normal account, or the guest account?
George
Eugene Mindrov
> Στις 17/5/2011 11:28, ο/η Eugene Mindrov έγραψε:
>
> Is your restricted account a normal account, or the guest account?
>
It's just a regular user account, not guest (I have it disabled). Local
groups membership for it:
Remote Desktop Users
Debugger Users
Users
--
Best regards,
Eugene
Eugene Mindrov
> Στις 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...
--
Best regards,
Eugene
Georgios Petasis
I have just created a new user, and tested. It works in my pc:
http://www.ellogon.org/~petasis/tcl/Images/bugs/Test.png
George
Eugene Mindrov
>
> I have just created a new user, and tested. It works in my pc:
>
> http://www.ellogon.org/~petasis/tcl/Images/bugs/Test.png
>
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 :)
--
Best regards,
Eugene
Georgios Petasis
What is the difference of these basekits and ActiveTcl's ones?
(SuRun may be required in XP, but I think there is no reason for using
it under Vista/7. You can run anything with administrator privileges,
after you ender a password.)
George
Eugene Mindrov
> Στις 17/5/2011 15:50, ο/η Eugene Mindrov έγραψε:
>
> What is the difference of these basekits and ActiveTcl's ones?
>
Really, I have no idea, but I clearly see the difference in behavior. I have
'build.cmd' script and when there's ActiveState basekit specified - nothing
works, but when it's replaced with the one from Google Code - it works.
> (SuRun may be required in XP, but I think there is no reason for using it
> under Vista/7. You can run anything with administrator privileges, after
> you ender a password.)
>
Yes, I agree, Vista and 7 both have much more convenient mechanism for
elevating privileges when required, but key benefit of SuRun over it is
that, for example, you can define your own white list of applications to run
elevated automatically without hassle of entering a password every time. I
find that much of a convenience.
--
Best regards,
Eugene
Jeff Hobbs
> "Georgios Petasis" <peta...@iit.demokritos.gr> wrote in message
Thanks for working through this to resolution. I should reiterate
that the one key difference with ActiveState basekits is that they
have additional code that allows for in-memory DLL loading. To do
this we need to override LoadLibrary*. Luckily SuRun posts their
source, and I see they do something similar. We'll look into this to
see if such a situation can be better handled.
Jeff