Installed 64bit tcl attached image but when I checked it with
% puts $tcl_platform(wordSize) it returns 4 means 32bit. Not sure why?
David
Here is the project link to my 64bit exe file,
https://platform.activestate.com/davidday47/Tcl-8.6.13-Windows11a/distributions
These are steps I took since there ar emultiple of tclsh.exe in my C:
1- go to C:\ActiveTcl\bin
2- >tclsh
3- %puts $tcl_platform(wordSize, it returns 4, that means it is 32bit
That is Tcl 8.6. Integers, pointers, and some other variables are limited to 32-bit sizes even though the binaries are 64-bit.
That limitation has been known for many years, and the plan has always been to introduce such a major breaking change at Tcl 9.
Thanbks for th einfo, so after all, it is 64bit. Then I am not sure why it can’t load library “…/tbcload1.7.dll”?
===============
global tcl_platform
set XFABPDK_KERNEL_ROOT “C:/sedatools/pdk/xfab-xt018-win/xt018/stdformats/v13_0/iPDK/v13_0_1”
set tbclib ${XFABPDK_KERNEL_ROOT}/scripts/generic/64bit/libtbcload1.7.so
if { [info exists tcl_platform(os)] } {
if { [regexp -nocase – {^windows} $tcl_platform(os)] } {
set tbclib ${XFABPDK_KERNEL_ROOT}/scripts/generic/64bit/tbcload1.7.dll
}
}
if { [catch {load $tbclib} errload] } {
puts “FATAL : byte coder functions are not available”
puts “–DEBUG-”
puts “$errload”
puts “–END—”
}
FATAL : byte coder functions are not available
–DEBUG-
couldn’t load library “C:/sedatools/pdk/xfab-xt018-win/xt018/stdformats/v13_0/iPDK/v13_0_1/scripts/generic/64bit/tbcload1.7.dll”: No error
–END—
If I do the following;
%package require tbcload
1.7 (return value)
so the tbcloader package is installed. I don’t know why there is an error?
David
I ran the Dependency Walker and came back with errors as attached
It looks like there are more packages to add but I am not sure…
Tried to add all the required packages, but now it can’t build the project. Here is my project link;
xhttps://platform.activestate.com/davidday47/Tcl-8.6.13-Windows-tbcload/distributions?platformID=78977bc8-0f32-519d-80f3-9043f059398c&branch=main
Error message attached;
Can you build the installer with the necessary packages for me? We can pay for it. However, I am not sure that would solve my originakl issue – Can’t load tbcload library.
Thanks
David - Looking into this issue…
David -
So generally - you can ignore all of those API-MS-Win DLLs - as long as you have the Visual C++ Redistributable for Visual Studio installed.
This TBCLOAD1.7 looks like it’s missing Tcl 8.5 - based on the DLL - that wouldn’t be the current install, but in this case you may just need to ensure that your Tcl 8.5 is on path - and discoverable by TBCLOAD1.7 at runtime.
The 8.6 build you linked to is working just fine, and has a TBCLOAD17.DLL runtime, but you’ll need to get your process to use it, and not the existing copy - again, you might have to put it on path once it’s installed so your process can find it.
*** If you can’t get this to work by adding tcl to the runtime path…
The best way I have found to truly diagnose these issues is to run procmon Process Monitor - Sysinternals | Microsoft Learn - with a filter on for the process you are running:
Process Name begins with tcl Include
Drop everything else - if your running through another process you may need to change tcl to that.
Then run the command that generates the error. You’ll get a huge log of results - Start from the bottom, and work up.
You’ll see NAME NOT FOUND errors in the results column - look for a big block of them - often a DLL is referenced and not found right away - if the needed DLL is located, you will see a SUCCESS for it at the bottom of the block of NAME NOT FOUND results.
What you are looking for is the DLL that is attemting to load, but is never found - once you locate that you will know what is missing at runtime.
When I tried to load tcl85t.dll, there is an error message. It can load but the entry-point DLLRegisterServer was not found. Not sure what I need to do next…
By the way I added the path to tcl85t.dll, but tbcload1.7.dll still unable to load.
If I add both tcl85t.dll and TBCLOAD1.7.dll paths, then the EDA tool will crash. Not sure why.
Well, if I use TBCLOAD17.DLL instead of TBCLOAD1.7.DLL, then the EDA tool have no issue to load it (TBCLOAD17.DLL). But it was from another EDA tool, I did not build it. What is the difference?
It looks like TBCLOAD17.DLL does not have dependence in Tcl8.5.
Is TBCLOAD17.DLL is coming from an ActiveState Distribution? If so that was built against Tcl 8.6, and I didn’t see an external dependency on Tcl itself - Could mean Tbcload is built with those bits statically, or the dependency is not needed for this version - It sounds like you’re mixing tcl versions between 8.5 and 8.6 - which might be causing some of these issues. Best recommendation is use one set of TCL modules, either 8.5 or 8.6, and remove or at least quarantine the other set.
Are you stuck on an older version of TCL?
Tcl8.6 is what’s required by the software vendor. TBCLOAD17.DLL is under C:\ActiveTcl\lib\tbcload1.7 folder, so I believe it was from the distribution. It does not have dependency on Tcl8.5. But the confusion was that the vendor provided TBCLOAD1.7.DLL does depend on Tcl8.5 based on “Dependency Walker” but I don’t know how to resolve the dependency. What is the right way to resolve this?
We are not stuck to an older version.
Thanks
If 8.6 is required, then use the newest tbcload you have access to always.
tbcload is highly backward compatible, but highly forward incompatible. A tbcload for 8.5 will be missing bytecode equivalents for all the new commands in 8.6, if any of those are attempted the bytecode will not translate, and it will crash.
It kind of sounds like you have either some parts of an older version of the vendor product, of that the vendor hasn’t completely removed all the cruft from older versions.