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

tbcload fails to compile against Tcl 8.5

140 views
Skip to first unread message

Wart

unread,
Jan 5, 2008, 4:50:20 PM1/5/08
to
tbcload fails to build against Tcl 8.5 due to some some #define changes
in tclInt.h:

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

George Peter Staplin

unread,
Jan 7, 2008, 12:45:43 AM1/7/08
to


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

Donal K. Fellows

unread,
Jan 7, 2008, 4:22:10 AM1/7/08
to
Wart wrote:
> I suspect that there were some bytecode changes between 8.4 and 8.5.

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.

Joi

unread,
Jan 7, 2008, 2:10:34 PM1/7/08
to
Hi,

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

Wart

unread,
Jan 7, 2008, 2:35:53 PM1/7/08
to
George Peter Staplin wrote:
> Wart wrote:
[...]

>> 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?
>
>
> 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.

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

Wart

unread,
Jan 7, 2008, 2:42:54 PM1/7/08
to
Joi wrote:
> Hi,
>
> 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

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

Donal K. Fellows

unread,
Jan 7, 2008, 6:40:19 PM1/7/08
to
Wart wrote:
> 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.

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.

0 new messages