cmpRead.c:156: error: 'VAR_SCALAR' undeclared here (not in a function)
cmpRead.c:159: error: 'VAR_UNDEFINED' undeclared here (not in a function)
cmpRead.c: In function 'ExtractObject':
cmpRead.c:1428: warning: dereferencing type-punned pointer will break
strict-aliasing rules
cmpRead.c: In function 'ExtractCompiledLocal':
cmpRead.c:2584: warning: assignment makes integer from pointer without a
cast
make: *** [cmpRead.o] Error 1
I hacked around this by defining both VAR_SCALAR and VAR_UNDEFINED to 0,
which works around the build failure. But the test suite than fails with:
==== cmpRead-2.2 CheckSignature - check version numbers FAILED
==== Contents of test case:
catchBceval [format {
TclPro ByteCode %d 0 %s %s
} [expr {$::tbcFormatVersion + 1}] $::tbcPackageVersion $::tcl_version]
---- Result was:
1 {bytecode terminated prematurely}
---- Result should have been (exact matching):
1 {unsupported bytecode version: 2}
==== cmpRead-2.2 FAILED
I suspect that there were some bytecode changes between 8.4 and 8.5.
Are there any plans to port the public tbcload sources to Tcl 8.5?
--Wart
I doubt it. Some people occasionally work on tbcload though.
Tbcload is mostly of interest to people that sell commercial software,
and want to make it proprietary, and conceal their source code. It
offers no performance improvement, as you probably already know.
Unfortunately I think it's a bad idea. IIRC tbcload disables [info
body] and [info args] tools for dynamic code, so that people can't
disassemble things as easily or get any sort of string rep as easily
from the bytecode image.
George
There were quite a few new bytecodes added, but most are not a
problem. What is a problem is that there are some that use new types
of metadata that weren't previously defined (requiring a more
sophisticated loader) and the way variables are laid out in memory was
changed too (which is what's causing you problems).
Donal.
The latest ActiveTcl sources include a patched tbcload, Jeff mentioned
the changes would be contributed once 8.5 was final, so it is probably
just a matter of time that the changes will be available in
sourceforge
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/fd4e9098ea96d395/11c279116b1ded14
Yes, I am aware. I'm not really interested in tbcload itself, but it is
referenced several times in the opensource Tclpro sources that I've
packaged for Fedora, which will be shipping with Tcl 8.5 for the next
release. If tbcload won't work with Tcl8.5, then I'll have to patch out
all of the references to it in the Tclpro sources and drop procompile
from the package as well.
--Wart
I hope so. I don't see any changes in the sourceforge CVS repository
for tbcload for over a year, though, so I won't hold my breath.
--Wart
I think you'll have to do that unless someone contributes the changes
to fix tbcload for 8.5 back into the free version of tclpro. (And
fixing procomp so that you can save 8.5 bytecodes will be harder.)
Donal.