Giter Club home page Giter Club logo

critcl's People

Contributors

adboomlodestar avatar andreas-kupries avatar andrewshadura avatar apnadkarni avatar gahr avatar jcw avatar jdc8 avatar joelface avatar patthoyts avatar snoe925 avatar stevel6868 avatar uu1101 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

critcl's Issues

Critcl doesn't work on OSX

Critcl doesn't seem to work on OSX (this is testing against Mountain Lion).

Tue Jan 14 21:06:50 GMT 2014 - /Users/dkf/Documents/software/RosettaCode/pokecode.tcl

gcc
    -c
    -fPIC
    -DUSE_THREAD_ALLOC=1
    -D_REENTRANT=1
    -D_THREAD_SAFE=1
    -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1
    -DHAVE_READDIR_R=1
    -DTCL_THREADS=1
    -DUSE_TCL_STUBS
    -I/Library/Tcl/teapot/package/tcl/lib/critcl3.1.7/critcl_c/tcl8.6
    -I/Users/dkf/.critcl/macosx-x86_64
    -o
    /Users/dkf/.critcl/macosx-x86_64/v317_6dec8315f054246c04a2864d82582461_pic.o
    /Users/dkf/.critcl/macosx-x86_64/v317_6dec8315f054246c04a2864d82582461.c
    -O2
    -DNDEBUG

pokecode.tcl: In function ‘c__runMachineCode4’:
pokecode.tcl:16: warning: incompatible implicit declaration of built-in function ‘memcpy’
/Users/dkf/.critcl/macosx-x86_64/v317_6dec8315f054246c04a2864d82582461_pic.o: 1400 bytes

gcc
    -shared
    -Wl,-s
    -o
    /Users/dkf/.critcl/macosx-x86_64/v317_6dec8315f054246c04a2864d82582461.dylib
    /Users/dkf/.critcl/macosx-x86_64/v317_6dec8315f054246c04a2864d82582461_pic.o

ld: warning: option -s is obsolete and being ignored
Undefined symbols for architecture x86_64:
  "_tclStubsPtr", referenced from:
      _Pokecode_Init in v317_6dec8315f054246c04a2864d82582461_pic.o
      _tcl__runMachineCode4 in v317_6dec8315f054246c04a2864d82582461_pic.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
ERROR while linking /Users/dkf/.critcl/macosx-x86_64/v317_6dec8315f054246c04a2864d82582461.dylib:
child process exited abnormally
Manifest Command: 
Manifest File:    <>, ignored

critcl build failed (/Users/dkf/Documents/software/RosettaCode/pokecode.tcl)
invalid command name "runMachineCode"
    while executing
"runMachineCode [binary format c* $code] 7 12"
    invoked from within
"puts [runMachineCode [binary format c* $code] 7 12]"
    (file "/Users/dkf/Documents/software/RosettaCode/pokecode.tcl" line 26)
Donals-MacBook-Pro:unix dkf$ tclsh8.6
% package names
activestate::teapot::link http platform zlib TclOO tcl::tommath tcltest msgcat ActiveTcl Tcl
% package require ActiveTcl
8.6.1.0.297577

This is critcl 3.1.7, obtained from the ActiveState teapot.

Remainder of conversation:

[21:13] dkf OK, here's the code itself
[21:13] dkf package require critcl
        
        critcl::tcl 8.6
        critcl::ccode {
            #include 
        }
        
        critcl::cproc runMachineCode {Tcl_Obj* codeObj int a int b} int {
            int size, result;
            unsigned char *code = Tcl_GetByteArrayFromObj(codeObj, &size);
            void *buf;
        
            /* copy code to executable buffer */
            buf = mmap(0, (size_t) size, PROT_READ|PROT_WRITE|PROT_EXEC,
                    MAP_PRIVATE|MAP_ANON, -1, 0); 
            memcpy(buf, code, (size_t) size);
            /* run code */
            result = ((int (*) (int, int))buf)(a, b);
            /* dispose buffer */
            munmap(buf, (size_t) size);
        
            return result;
        }
        
        set code {0x8B 0x44 0x24 0x4  0x3 0x44 0x24 0x8  0xC3}
        puts [runMachineCode [binary format c* $code] 7 12]
[21:13] aku Semi-conventional. Compile&run mode then. I thought you are using the critcl app like 'critcl -pkg pokecode.tcl'
[21:13] dkf it's a putative Tcl solution to a Rosetta Code problem
[21:13] dkf I don't have a critcl on my path
[21:14] dkf 
[21:14] aku You got critcl out of the teapot ?
[21:14] dkf I think so
[21:14] dkf Or maybe it came with the 8.6 build; it's an ActiveState one
[21:15] dkf % package require ActiveTcl
        8.6.1.0.297577
[21:15] aku It is not installed by default, so it must be teapot. And 317 is what we currently have in teapot.
[21:15] aku I have to fix this, nbot having the critcl app ... 
[21:16] aku App is very simple:
        #!/bin/sh
        # -*- tcl -*- \
        exec tclsh "$0" ${1+"$@"}
        package require critcl
        package require critcl::app
        critcl::app::main $argv
[21:17] aku I will try to build this code here, maybe I rn into the same issue on linux or other OSX
[21:17] aku I currently do not see how it is failing. Likely something in the compile&run mode has slipped
[21:20] dkf Well, you've got what I've got
[21:20] dkf (I don't know if my code works yet, but I know it shouldn't fail like that.)
[21:20] aku Oh, the code variable, that is intel machine code ?
[21:21] dkf It also doesn't work (in the same way) when I try to build it as a package
[21:21] dkf yes
[21:21] dkf http://rosettacode.org/wiki/Machine_code
[21:21] aku Does it use 64bit insn, or is 32bit good enough ?
[21:21] dkf Pass 
[21:22] aku  ... rosettacode not responding ... Ok, I will see what happens on 32bit linux, now...
[21:22] dkf If it crashes in a mess, I know it will be doing (almost) the right thing
[21:23] dkf RC's been dodgy network-wise recently
[21:23] aku On linux 32bit I get an output of 19
[21:23] aku and rosetta has timed out, claims to be offline 
[21:24] aku (And no crash)
[21:24] aku Now for OSX ...
[21:25] aku (That was critcl 3.1.6 btw).
[21:26] dkf the failure mode I'm getting is definitely not what I might be lead to expect 
[21:32] aku So, not something specific to m.lion, but specific to OSX at least
[21:32] dkf I'm guessing a missing definition or something
[21:32] aku So, bug confirmed. Please report on the critcl github issue tracker
[21:32] dkf will do

cresults documentation, and log reporting.

After a compile failure, this dict returned by critcl::cresults has an empty 'log' key. I'm not clear what the man page for critcl::cresults means - is 'log' only populated after a failure, and only when the build is triggered by ::critcl::buildforpackage ?

I'd like to have the log contain just the compiler messages. Having re-defined ::critcl::print as per docs to capture logging from critcl and parsing the log messages for my project, I'd like to have some log that is just the compiler log and not the information that critcl prints, e.g., timestamp & filename, compiler used, compiler flags, the compiler output, a Tcl error, and a few interspersed whitespace lines.

Test case:

package require critcl
critcl::cproc fudge  {char* s} char*  {return booger ;}
set result [critcl::load]
set result_dict [critcl::cresults]
puts "result: $result"
puts "   log: [dict get $result_dict log]"

whereas the ::critcl::print command prints:

Tue May 05 20:09:58 MDT 2015 - /home/tpoindex/crit-load-test.tcl

gcc
    -c
    -fPIC
    -DUSE_THREAD_ALLOC=1
    -D_REENTRANT=1
    -D_THREAD_SAFE=1
    -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1
    -DHAVE_READDIR_R=1
    -DTCL_THREADS=1
    -DUSE_TCL_STUBS
    -I/home/tpoindex/src/tcl/critcl-3.1.13-test/lib/critcl/critcl_c/tcl8.4
    -I/home/tpoindex/.critcl/linux-ix86
    -o
    /home/tpoindex/.critcl/linux-ix86/v3113_9a72bf1aaa8aec9265bd35f7d545d587_pic.o
    /home/tpoindex/.critcl/linux-ix86/v3113_9a72bf1aaa8aec9265bd35f7d545d587.c
    -O2
    -DNDEBUG

crit-load-test.tcl: In function ‘c__fudge0’:
crit-load-test.tcl:3:8: error: ‘booger’ undeclared (first use in this function)
crit-load-test.tcl:3:8: note: each undeclared identifier is reported only once for each function it appears in
ERROR while compiling code in /home/tpoindex/crit-load-test.tcl:
child process exited abnormally

critcl build failed (/home/tpoindex/crit-load-test.tcl)

What I really want is just the three lines of compiler errors. Parsing these out is obviously compiler dependent.

TEA build leaves a make file with empty targets

Using the -tea option builds a tea package and the configure also runs without errors. However the generated makefile does nothing because the targets have no dependencies and there are no active rules in the makefile.

Tried with the latest release (3.1.9 - btw, the package require returns 3.1.8) on Linux (actually core.tcl.tk)

/Ashok

Check the availability of Tcl headers to allow building against system-provided ones

It may be useful to replace Tcl headers shipped with Critcl with symlinks to well-known places where distribution-provided headers reside, in which case Critcl would need to detect which of them are actually available, and use those with a minimum satisfying version. This patch adds simple logic to perform that check.

--- a/lib/critcl/critcl.tcl
+++ b/lib/critcl/critcl.tcl
@@ -3647,7 +3647,13 @@
 }

 proc ::critcl::MinTclVersion {file} {
-    return [GetParam $file mintcl 8.4]
+    set required [GetParam $file mintcl 8.4]
+    foreach version $v::hdrsavailable {
+   if {[package vsatisfies $version $required]} {
+       return $version
+   }
+    }
+    return $required
 }

 proc ::critcl::UsingTk {file} {
@@ -4553,6 +4559,10 @@
     variable v::buildplatform [BuildPlatform]
     variable v::hdrdir       [file join $mydir critcl_c]

+    foreach d [lsort -dict [glob -types {d r} -directory $v::hdrdir -tails tcl*]] {
+   lappend v::hdrsavailable [regsub {^tcl} $d {}]
+    }
+
     # The prefix is based on the package's version. This allows
     # multiple versions of the package to use the same cache without
     # interfering with each. Note that we cannot use 'pid' and similar
@@ -4771,6 +4781,9 @@
    variable hdrdir          ;# Path. Directory containing the helper
                  # files of the package. A sub-
                  # directory of 'mydir', see above.
+   variable hdrsavailable   ;# Headers versions available. Used when
+                 # building against system-provided Tcl
+                 # headers
    variable prefix          ;# String. The string to start all file names
                  # generated by the package with. See
                  # 'Initialize' for our choice and

critcl::ccommand -clientdata argument not used in Tcl_CreateObjCommand

Critcl version 3.1.10

In my zeromq wrapper I'm using a critcl::cccommand like this:

critcl::ccommand ::zmq::context {cd ip objc objv} {
....
} -clientdata zmqClientDataInitVar

In the critcl generated code the clientdata is not used:

Tcl_CreateObjCommand(ip, ns__zmq_context24, tcl__zmq_context24, NULL, 0);

Jos.

couldn't load library

I downloaded the latest critcl from github, installed it under tcl86 based on instructions in the README file. After installation I tried out the examples/stack. When I tried to require the stackc package using tcl86 I got the following error:
couldn't load library: "C:/critcl/examples/stack/lib/stackc/win32-x86_64/stackc.dll": invalid argument

PS: I am using Windows 10 and Tcl version 8.6

critcl sorts the libraries specified with criticl::clibraries

Hi,

When specifying libraries with the critcl::clibraries command, these are added to the final link command sorted. The following patch removes the sort and allows duplicates as sometimes needed:

diff --git a/lib/app-critcl/critcl.tcl b/lib/app-critcl/critcl.tcl
index 01fb13d..e077bc5 100644
--- a/lib/app-critcl/critcl.tcl
+++ b/lib/app-critcl/critcl.tcl
@@ -819,7 +819,7 @@ proc ::critcl::app::BuildBracket {} {
     eval $lib

     set                 lib critcl::clibraries
-    critcl::lappendlist lib [lsort -unique $v::clibraries]
+    critcl::lappendlist lib $v::clibraries
     eval $lib

     eval [linsert [lsort -unique $v::ldflags] 0 critcl::ldflags]

md5 explicitly sourced, leading to problems on default install

Critcl assumes it will find md5/ in its parent directory, which is apparently an unwarranted assumption.

I think, at least, it should depend upon the [package] facility to locate the md5 package, or at most build.tcl should ensure a copy of md5/ is present where critcl later tries to source it. I think the former solution is better, as I'm not sure [info library] is always the place to find md5/

Colin

ERROR:

$ critcl
couldn't read file "/usr/lib/tcl8.6/critcl3.1.15/../md5/md5.tcl": no such file or directory
while executing
"source [file join [file dirname [info script]] ../md5/md5.tcl]"
(file "/usr/lib/tcl8.6/critcl3.1.15/critcl.tcl" line 56)
invoked from within
"source /usr/lib/tcl8.6/critcl3.1.15/critcl.tcl"
("package ifneeded critcl 3.1.15" script)
invoked from within
"package require critcl"
(file "/usr/lib/tcl8.6/critcl-app3.1.15/critcl.tcl" line 22)
invoked from within
"source /usr/lib/tcl8.6/critcl-app3.1.15/critcl.tcl"
("package ifneeded critcl::app 3.1.15" script)
invoked from within
"package require critcl::app"
(file "/usr/bin/critcl" line 4)

INSTALL:
$ sudo tclsh ./build.tcl install
Installing into:
Packages: /usr/lib/tcl8.6
Application: /usr/bin

Installed package: /usr/lib/tcl8.6/critcl3.1.15
Installed package: /usr/lib/tcl8.6/critcl-util1.1
Installed package: /usr/lib/tcl8.6/critcl-class1.0.6
Installed package: /usr/lib/tcl8.6/critcl-iassoc1.0.2
Installed package: /usr/lib/tcl8.6/critcl-literals1.1
Installed package: /usr/lib/tcl8.6/critcl-enum1.0.1
Installed package: /usr/lib/tcl8.6/critcl-bitmap1.0.1
Installed package: /usr/lib/tcl8.6/critcl-emap1
Installed package: /usr/lib/tcl8.6/critcl-app3.1.15
Installed package: /usr/lib/tcl8.6/util84
Installed package: /usr/lib/tcl8.6/stubs
Installed package: /usr/lib/tcl8.6/critcl-platform
Installed application: /usr/bin/critcl

critcl 3.1.7 and 3.1.6 behave differently when used scripted and interactively respectively

If I call the attached script using tclsh test.tcl I will get the error

Error in startup script

invalid command name "triple"
while executing
"triple 123"
invoked from within
"puts "three times 123 is [triple 123]""
(file "D:\Temp\critcl\test.tcl" line 8)

OK

There are linker errors about "...undefined reference to `tclStubsPtr'...".

However, if I start the tclsh interactively and copy and paste the contents of test.tcl then it will work as expected.

critcl 3.1.3 works as expected in both cases.
I have ActiveState Tcl 8.5.12 and installed critcl via teacup.
I have Mingw 4.6.2 in Win2k.

Compiling C++ with "-x c++" is unsupported by cl.exe

The equivalent option is -TP.

Should this be part of the compiler configuration? Something like:
linux-x86_64-gcc cpp -xc++
win32-x86_64-cl cpp -TP

It would also be useful to be able to configure the C++ libraries (-lstdc++ on Linux) too.

Default cache-path not specific enough

critcl tries to use a different subdirectory under ~/.critcl for each $OS-$ARCH combination -- in anticipation that the same home directory may be shared by the user on multiple computers.

Unfortunately, this is not enough -- and the operating system's release number should be part of it too. Because binaries built, for example, on FreeBSD-8 would be different from those built on FreeBSD-10, even if the architecture is the same. Same, likely, goes for SunOS, Linux-distros, et cætera.

critcl constants

We already have cdata for strings and bytearrays.
We should have something for constants of all types ... For which we have a proper result type conversion. Ex:
critcl::const foo boolean 1
=> Generates a command [foo] returning 1, as proper boolean Tcl_Obj.

We can currently do this with a proper cproc, i.e. the above would be
critcl::cproc foo {} boolean { return 1; }
However with const we can know that the result is fixed, and drop the internal C function, and just put the value in the proper place.

With cproc we have to assume that the compiler will inline the superfluous function.

critcl::reset for multiple compilations

Critcl currently only allows one compilation per program execution, here is an example:

$ tclsh8.6
% package require critcl
3.1.12
% critcl::cproc foo {} int {return 1;}
% foo
1
% critcl::cproc bar {} int {return 2;}
critcl::cproc (level 2 cmd {critcl::cproc bar {} int {return 2;}} line 1 type eval): Illegal attempt to define C code in  after it was built.

I propose a "critcl::reset" command be added, so that multiple compilations are supported. I have a quick-and-dirty patch to do this. The patch works by saving the critcl namespace variables and arrays, and restoring that state when critcl::reset is called.

*** critcl.tcl.orig 2014-11-20 11:35:19.115447013 -0700
--- critcl.tcl  2014-11-20 12:33:14.360826503 -0700
***************
*** 4847,4856 ****
--- 4847,4899 ----
      return
  }

+ proc ::critcl::InitialState {} {
+     variable _initialState
+     foreach _ns [concat [namespace current] [namespace children]] {
+         dict set _initialState $_ns [namespace eval $_ns {
+             set _arrays []
+             set _vars []
+             foreach _v [lsort [info vars]] {
+                 if {[regexp {^(_)|(arg)|(auto_)|(env)|(errorInfo)|(tcl_)|(history).*} $_v]} {
+                     continue
+                 }
+                 if {[array exists $_v]} {
+                     if {[catch {lappend _arrays $_v [array get $_v]}]} {
+                         lappend _arrays $_v {}
+                     }
+                 } else {
+                     if {[catch {lappend _vars   $_v [set $_v]}]} {
+                         lappend _vars $_v {}
+                     }
+                 }
+             }
+             list arrays $_arrays vars $_vars
+         }]
+     }
+     rename ::critcl::InitialState {}
+     return 
+ }
+ 
+ proc ::critcl::reset {} {
+     variable _initialState
+     foreach ns [concat [namespace current] [namespace children]] {
+         lassign [dict get $_initialState $ns] arrays arraydata vars vardata
+         foreach {_v _d} $arraydata {
+             unset ${ns}::$_v
+             array set ${ns}::$_v $_d
+         }
+         foreach {_v _d} $vardata {
+             set ${ns}::$_v $_d
+         }
+     }
+     return 
+ }
+ 
  # # ## ### ##### ######## ############# #####################
  ## State

  namespace eval ::critcl {
+     variable _initialState ;# state of package arrays/variables after initialization
      variable mydir    ;# Path of the critcl package directory.
      variable run      ;# interpreter to run commands, eval when, etc

***************
*** 5019,5024 ****
--- 5062,5068 ----

    variable code            ;# This array collects all code snippets and
                  # data about them.
+         array set code {}

    # Keys for 'code' (above) and their contents:
    #
***************
*** 5206,5209 ****
--- 5250,5254 ----
  ## Ready

  ::critcl::Initialize
+ ::critcl::InitialState
  return

"sudo tclsh ./build.tcl install" permissions

When I do "tclsh ./build.tcl install" to install critcl, it ends up placing the files in /usr/bin/, etc - which isn't normally writable.

Using "sudo tclsh ./build.tcl install" to overcome this produces a "/usr/bin/critcl" which is not runnable by others than root.

Probably neither /usr/bin/ nor sudo are a good idea, but when you start with "apt-get install tcl", that's how things are set up on Linux Debian.

missing value to go with key

critcl works fine in an ActiveTcl 8.5.18 install I have, however, I'm also trying to use it inside an embedded Tcl8.5.9 interpreter. In that last case, package require tcl works fine, but as soon as it hits a ::critcl::cproc I get this error

missing value to go with key
    while executing
"dict exists has $t"
    (procedure "ArgsInprocess" line 45)
    invoked from within
"ArgsInprocess $adefs $aoffset"
    (procedure "::critcl::cproc" line 21)

Running on win7 with mingw64, I'm pretty sure I have all required packages installed.

Every class needs to have a classvariable

The following definition

critcl::class::define x {
    insvariable int ivar
}

results in a compiler error. The following works:

critcl::class::define x {
    classvariable int cvar
    insvariable int ivar
}

The first results in an error because critcl creates an empty struct definition for the class which is rejected by the C compiler. Not clear if this is a bug or a documentation issue (saying every class definition must have a classvariable)

The -tea option on Windows/msys/mingw fails because it cannot exec autoconf

Using the command tclsh critcl -tea ... fails on Windows/msys/mingw because it tries to [exec autoconf]. Even if msys/mingw is in the path, the exec command on Windows will not directly execute autoconf as it is a shell script, not a exe or any file "known" to Windows. To fix this, change line 1546 in critcl.tcl from

exec [LocateAutoconf]

to

exec sh [LocateAutoconf]

Also, line 1670

    set v [lindex [split [eval [linsert [linsert $ac 0 exec] end --version]] \n] 0 end]

should be changed to

    set v [lindex [split [eval [linsert [linsert $ac 0 exec sh] end --version]] \n] 0 end]

Just a little typo ...

Just a little typo in: embedded/www/doc/files/critcl_introduction.html#section7

Changes for version 3.1

Extended the API for handling TEApot metadata. Added the command meta? to query the stored infomration. Main use currently envisioned is retreieval of the current package's name by utility command, for use in constructed names. This particular infomration is always available due to the static scan of the package file on execution of the first critcl command.

bufferoverflowU.lib selected differently in debug and release mode

This lib is selected conditionally in debug mode but unconditionally in release mode. I think both cases should be conditional. Update for Config:

win32-x86_64-cl link_release -release -opt:ref -opt:icf,3 -ws:aggressive -verbose:lib bufferoverflowU.lib

should become:

win32-x86_64-cl link_release -release -opt:ref -opt:icf,3 -ws:aggressive -verbose:lib $msvcbufferoverflowlib

Wrong directory name building 32-bit Linux extension on 64-bit Linux

On a 64-bit Linux system, building using options -pkg -target linux-32-* results in a successful build but the directory name where the .so is placed is named "linux-32-*" while the pkgIndex will try to load it from linux-ix86 and thereby fail. Load succeeds if the directory is manually renamed.

Missing package requirement in docs: mk4tcl

I ran: critcl -help
Output:
"Can't find package Mk4tcl
Couldn't load the Critcl help Wiki
To display the Critcl help wiki run "critcl" without any options."

I needed more help. What is Mk4tcl? Time to google it. Ah, something called Metakit.
Looks like another package requirement to add to the docs.

Thanks for all your great work!

Build issues

Build fails using tclsh 8.4? May or may not be worth investigating. Might at least warn.

john@home : sudo tclsh ./build.tcl install
Installing into:
Packages: /sw/lib/tcl8.4
Application: /sw/bin

Installed package: /sw/lib/tcl8.4/critcl3.1.5
Installed package: /sw/lib/tcl8.4/critcl-util1
Installed package: /sw/lib/tcl8.4/critcl-class1.0.5
Installed package: /sw/lib/tcl8.4/critcl-iassoc1.0.1
Installed package: /sw/lib/tcl8.4/critcl-app3.1.5
Installed package: /sw/lib/tcl8.4/util84
Installed package: /sw/lib/tcl8.4/stubs
Installed application: /sw/bin/critcl
john@home :
john@home :
john@home : /sw/bin/critcl
can't find package platform 1.0.2
while executing
"package require platform 1.0.2 "
(file "/sw/lib/tcl8.4/critcl3.1.5/critcl.tcl" line 15)
invoked from within
"source /sw/lib/tcl8.4/critcl3.1.5/critcl.tcl"
("package ifneeded" script)
invoked from within
"package require critcl"
invoked from within
"package provide critcl::app [package require critcl]"
(file "/sw/lib/tcl8.4/critcl-app3.1.5/critcl.tcl" line 22)
invoked from within
"source /sw/lib/tcl8.4/critcl-app3.1.5/critcl.tcl"
("package ifneeded" script)
invoked from within
"package require critcl::app"
(file "/sw/bin/critcl" line 4)

critcl::cinit can not be used for c89

The code specified with critcl::cinit is inserted in the generated Init function after the call to MyInitTclStubs. This makes it impossible to create e.g. a client data objects when using ansi-c because the variable definition comes after the call. Workaround is to use a static (file scope) variable;

Incorrect link flags building 32-bit Linux extension on 64-bit Linux

When target is linux-32-* while building on a 64-bit Linux, the compiler (gcc) is correctly passed the -m32 flag. However, the link command does not include this flag causing the linker to attempt to link a 64-bit output using 32-bit input files. Patch to fix this below

*** Config.orig 2013-03-26 21:33:21.000000000 -0700
--- Config      2013-03-27 05:07:56.000000000 -0700
***************
*** 257,263 ****
--- 257,266 ----
  # Linux - 32 bit or 64 bit build - select using "-target" if you don't want
  #         the platform default (32 on 32, 64 on 64)
  linux-32-*  compile   gcc -c -m32
+ linux-32-*  link      gcc -shared -m32
  linux-64-*  compile   gcc -c -m64
+ linux-64-*  link      gcc -shared -m64
+

  # Windows - Check if bufferoverflowU.lib is required, or not. We
  # assume that "requiredness" coincides with "presence". IOW, if the

Parameter inconsistency

The interpreter argument is sometimes named ip, other times interp. For example, the whole ::critcl::class module uses interp, but ::critcl::cinit makes ip available. The latter is not documented.

In my opinion, critcl should use a homogeneous naming convention when the parameter names are not configurable by the user (as is the case with ::critcl::ccommand, for example).

./build.tcl help - fails on FreeBSD

$ ./build.tcl help
can't read "errorInfo": no such variable
while executing
"if {($errorInfo ne {}) &&
![string match {invalid command name "__"_} $errorInfo]
} {
puts stderr $::errorInfo
exit
}"
(procedure "usage" line 3)
invoked from within
"usage 0"
(procedure "_help" line 2)
invoked from within
"_help"
("eval" body line 1)
invoked from within
"eval _$argv"

I have used the critcl master branch on a FreeBSD 8.2 installation

On my Linux system all is perfect.

unversioned critcl packages

Critcl installs the packages "stubs", "util84", "critcl-platform", and "critcl-emap1" into directories that don't include any version information. This leaves the door open for contention between installations of different versions of criticl. Could these directories also be versioned?

critcl::enum - limitations and warnings

Warning:
xxx_GetFromObj ... strings (@TSIZE@)
=> size+1 to account for the NULL.

Limitation

  • Currently cannot use defines for the symbol names. They are used for the literal pool enum, and the define replacements then breaks C syntax! The pool index enum and the 'enum symbols' must be separate, and mapped through secondary arrays.

Extension:

  • Such indirect mapping may also allow a multi-mapping of symbols to different strings, i.e. multiple strings to the same symbol.

::critcl::load does not return error when compile fails

I am using ::critcl::ccode and ::critcl::ccommand to define a Tcl command, and invoke ::critcl::load to compile and load. I have also defined ::critcl::cflags -Werror=return-type to have gcc raise an error when a return type does not match the function definition. ::critcl::load does not raise a Tcl error when the compilation fails.

Here is a sample to demostrate the behavior:

package require critcl 3.1.13
set name bar
set helper_function {Tcl_WideInt TSP_UserDirect_foo() {}}
set tcl_cmd_interface {TSP_UserDirect_foo(); return TCL_OK;}
set rc [ catch {
    ::critcl::tcl 8.5
    ::critcl::cflags -Werror=return-type
    ::critcl::ccode  $helper_function
    ::critcl::ccommand ::$name {clientData interp objc objv} $tcl_cmd_interface
    ::critcl::load
} result ]
puts "rc = $rc"

Gcc will cause the compile to fail with the -Werror=return-type flag, and the critcl log for the compile shows the compile failure:

.critcl/linux-ix86/v3113_6f060491c56fdbd9f4088125bc1a3a79.c: In function ‘TSP_UserDirect_foo’:
.critcl/linux-ix86/v3113_6f060491c56fdbd9f4088125bc1a3a79.c:10:1: error: control reaches end of non-void function [-Werror=return-type]
 Tcl_WideInt TSP_UserDirect_foo() {}
 ^
cc1: some warnings being treated as errors
ERROR while compiling code in :
child process exited abnormally

critcl build failed ()

In the above Tcl code, the 'catch' block returns 0 as rc, and a Tcl error is not raised.

Expected behavior:
::critcl::load should return 1, and raise a Tcl error.

C++ won't link?

Here is the top of my .critcl file:

#!/Users/john/bin/tclkit8.6

critcl::cheaders acorn.h -I/Users/john/include -I/home/john/include
#critcl::tsources acorn.tcl

critcl::config language c++
critcl::clibraries -lstdc++

namespace eval acorn {
critcl::ccode {
#include
#include <Eigen/Dense>

    using namespace std;
    using namespace Eigen;

    #include "acorn.h"

Then when I make the package I get:

critcl31 -force -pkg acorn
Compilation forced
Config: linux-x86_64-gcc
Build: linux-x86_64-gcc
Target: linux-x86_64
Source: acorn.tcl (provide acorn 1.0)
Library: acorn.so

Sat Jan 26 15:50:08 EST 2013 - /home/john/src/aco/acorn/acorn.so

gcc
-c
-fPIC
-DUSE_THREAD_ALLOC=1
-D_REENTRANT=1
-D_THREAD_SAFE=1
-DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1
-DHAVE_READDIR_R=1
-DTCL_THREADS=1
-DUSE_TCL_STUBS
-x
c++
-I/home/john/.critcl/pkg29744.1359233407/tcl8.4
-I/home/john/.critcl/pkg29744.1359233407
-o
/home/john/.critcl/pkg29744.1359233407/v311_df389c78cd68789ba393b8829a790c70_pic.o
/home/john/.critcl/pkg29744.1359233407/v311_df389c78cd68789ba393b8829a790c70.c
-x
none
-O2
-DNDEBUG

MyInitTclStubs: In function ‘int MyInitTclStubs(Tcl_Interp_)’:
MyInitTclStubs:21:21: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
/home/john/.critcl/pkg29744.1359233407/v311_df389c78cd68789ba393b8829a790c70_pic.o: 2328 bytes

gcc
-shared
-Wl,-s
-o
/home/john/.critcl/pkg29744.1359233407/v311_df389c78cd68789ba393b8829a790c70.so
/home/john/.critcl/pkg29744.1359233407/v311_df389c78cd68789ba393b8829a790c70_pic.o
/home/john/.critcl/pkg29744.1359233407/v311_1b2dc3713ac5c068af04d3d0e28fac47_pic.o
-lstdc++

/home/john/.critcl/pkg29744.1359233407/v311_1b2dc3713ac5c068af04d3d0e28fac47_pic.o:(.bss+0x18): multiple definition of tclStubsPtr' /home/john/.critcl/pkg29744.1359233407/v311_df389c78cd68789ba393b8829a790c70_pic.o:(.bss+0x18): first defined here /home/john/.critcl/pkg29744.1359233407/v311_1b2dc3713ac5c068af04d3d0e28fac47_pic.o:(.bss+0x10): multiple definition oftclPlatStubsPtr'
/home/john/.critcl/pkg29744.1359233407/v311_df389c78cd68789ba393b8829a790c70_pic.o:(.bss+0x10): first defined here
/home/john/.critcl/pkg29744.1359233407/v311_1b2dc3713ac5c068af04d3d0e28fac47_pic.o:(.bss+0x8): multiple definition of tclIntStubsPtr' /home/john/.critcl/pkg29744.1359233407/v311_df389c78cd68789ba393b8829a790c70_pic.o:(.bss+0x8): first defined here /home/john/.critcl/pkg29744.1359233407/v311_1b2dc3713ac5c068af04d3d0e28fac47_pic.o:(.bss+0x0): multiple definition oftclIntPlatStubsPtr'
/home/john/.critcl/pkg29744.1359233407/v311_df389c78cd68789ba393b8829a790c70_pic.o:(.bss+0x0): first defined here
collect2: ld returned 1 exit status
ERROR while linking /home/john/.critcl/pkg29744.1359233407/v311_df389c78cd68789ba393b8829a790c70.so:
child process exited abnormally
Manifest Command:
Manifest File: <>, ignored

critcl build failed (/home/john/src/aco/acorn/acorn.so)
(FAILED) Files left in /home/john/.critcl/pkg29744.1359233407
FAILURES 1
FAILED: <>
FAILED
make: *** [lib/acorn/pkgIndex.tcl] Error 1

Multiple self-test failures in 3.1.14

Testing on FreeBSD-9/i386, with Tcl-8.6, I got the below output. One problem is that LogClose does not check, whether error-log exists -- and insists on opening it. The other is missing AbortWhenCalledAfterBuild -- it is mentioned in documentation, invoked by critcl::cconst, but not defined anywhere...

Frankly, why bother with a test-suite, if a release can be created without running through all the tests cleanly?

(cd /mi/ports/devel/critcl/work/critcl-3.1.14 && /opt/bin/tclsh8.6 test/all.tcl)

_ _ __ ___ _____ ________ _____________ _____________________ *** cache.test ***
- tcllib::testutils 1.2
- lassign84 1.0.1
- dict84 1
- stubs::container 1
- stubs::reader 1
- stubs::gen 1
* critcl 3.1.13
cache.test:     Total   5       Passed  3       Skipped 2       Failed  0
Number of tests skipped for each constraint:
        1       tcl84
        1       tcl85

_ _ __ ___ _____ ________ _____________ _____________________ *** ccommand.test ***
- tcllib::testutils 1.2
- lassign84 1.0.1
- dict84 1
- stubs::container 1
- stubs::reader 1
- stubs::gen 1
* critcl 3.1.13


==== critcl-ccommand-3.0 ccommand, defaults FAILED
==== Contents of test case:

    critcl::ccommand command {} { return TCL_OK; }
    critcl::cbuild [the-file]
    inspect v*.c

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: couldn't open "/mi/ports/devel/critcl/work/critcl-3.1.14/test/CACHE/84158.log_": no such file or directory
    while executing
"open $path r"
    (procedure "Cat" line 5)
    invoked from within
"Cat ${v::logfile}_"
    (procedure "LogClose" line 7)
    invoked from within
"LogClose"
    (procedure "critcl::cbuild" line 75)
    invoked from within
"critcl::cbuild [the-file]"
    ("uplevel" body line 3)
    invoked from within
"uplevel 1 $script"
---- errorCode: POSIX ENOENT {no such file or directory}
==== critcl-ccommand-3.0 FAILED



==== critcl-ccommand-3.4 ccommand, -delproc FAILED
==== Contents of test case:

    critcl::ccommand command {} { return TCL_OK; } -delproc DELE
    critcl::cbuild [the-file]
    inspect v*.c

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: couldn't open "/mi/ports/devel/critcl/work/critcl-3.1.14/test/CACHE/84158.log_": no such file or directory
    while executing
"open $path r"
    (procedure "Cat" line 5)
    invoked from within
"Cat ${v::logfile}_"
    (procedure "LogClose" line 7)
    invoked from within
"LogClose"
    (procedure "critcl::cbuild" line 75)
    invoked from within
"critcl::cbuild [the-file]"
    ("uplevel" body line 3)
    invoked from within
"uplevel 1 $script"
---- errorCode: POSIX ENOENT {no such file or directory}
==== critcl-ccommand-3.4 FAILED



==== critcl-ccommand-3.5 ccommand, -clientdata FAILED
==== Contents of test case:

    critcl::ccommand command {} { return TCL_OK; } -clientdata ABC
    critcl::cbuild [the-file]
    inspect v*.c

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: couldn't open "/mi/ports/devel/critcl/work/critcl-3.1.14/test/CACHE/84158.log_": no such file or directory
    while executing
"open $path r"
    (procedure "Cat" line 5)
    invoked from within
"Cat ${v::logfile}_"
    (procedure "LogClose" line 7)
    invoked from within
"LogClose"
    (procedure "critcl::cbuild" line 75)
    invoked from within
"critcl::cbuild [the-file]"
    ("uplevel" body line 3)
    invoked from within
"uplevel 1 $script"
---- errorCode: POSIX ENOENT {no such file or directory}
==== critcl-ccommand-3.5 FAILED

ccommand.test:  Total   12      Passed  7       Skipped 2       Failed  3
Number of tests skipped for each constraint:
        1       tcl84
        1       tcl85

_ _ __ ___ _____ ________ _____________ _____________________ *** cconst.test ***
- tcllib::testutils 1.2
- lassign84 1.0.1
- dict84 1
- stubs::container 1
- stubs::reader 1
- stubs::gen 1
* critcl 3.1.13


==== critcl-cconst-1.4 cconst, bad result type (void) FAILED
==== Contents of test case:

    critcl::cconst N void T

---- Result was:
invalid command name "AbortWhenCalledAfterBuild"
---- Result should have been (exact matching):
Constants cannot be of type "void"
==== critcl-cconst-1.4 FAILED



==== critcl-cconst-2.0 cconst, bool, fixed value FAILED
==== Contents of test case:

    get critcl::cconst alpha bool 1

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: invalid command name "AbortWhenCalledAfterBuild"
    while executing
"AbortWhenCalledAfterBuild"
    (procedure "critcl::cconst" line 13)
    invoked from within
:    invoked from within
"critcl::cconst alpha bool 1"
    ("uplevel" body line 1)
    invoked from within
"uplevel 1 $script"
    (procedure "critcl::collect" line 3)
    invoked from within
"critcl::collect $args"
    (procedure "get" line 2)
    invoked from within
"get critcl::cconst alpha bool 1"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $script"
---- errorCode: TCL LOOKUP COMMAND AbortWhenCalledAfterBuild
==== critcl-cconst-2.0 FAILED



==== critcl-cconst-2.1 cconst, bool, define FAILED
==== Contents of test case:

    get critcl::cconst alpha bool FOO

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: invalid command name "AbortWhenCalledAfterBuild"
    while executing
"AbortWhenCalledAfterBuild"
    (procedure "critcl::cconst" line 13)
    invoked from within
"critcl::cconst alpha bool FOO"
    ("uplevel" body line 1)
    invoked from within
"uplevel 1 $script"
    (procedure "critcl::collect" line 3)
    invoked from within
"critcl::collect $args"
    (procedure "get" line 2)
    invoked from within
"get critcl::cconst alpha bool FOO"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $script"
---- errorCode: TCL LOOKUP COMMAND AbortWhenCalledAfterBuild
==== critcl-cconst-2.1 FAILED
==== critcl-cconst-2.2 cconst, bool, function FAILED
==== Contents of test case:

    get critcl::cconst alpha bool foo()

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: invalid command name "AbortWhenCalledAfterBuild"
    while executing
"AbortWhenCalledAfterBuild"
    (procedure "critcl::cconst" line 13)
    invoked from within
"critcl::cconst alpha bool foo()"
    ("uplevel" body line 1)
    invoked from within
"uplevel 1 $script"
    (procedure "critcl::collect" line 3)
    invoked from within
"critcl::collect $args"
    (procedure "get" line 2)
    invoked from within
"get critcl::cconst alpha bool foo()"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $script"
---- errorCode: TCL LOOKUP COMMAND AbortWhenCalledAfterBuild
==== critcl-cconst-2.2 FAILED

==== critcl-cconst-2.3 cconst, namespaced name FAILED
==== Contents of test case:

    get critcl::cconst the::alpha bool 0

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: invalid command name "AbortWhenCalledAfterBuild"
    while executing
"AbortWhenCalledAfterBuild"
    (procedure "critcl::cconst" line 13)
    invoked from within
"critcl::cconst the::alpha bool 0"
    ("uplevel" body line 1)
    invoked from within
"uplevel 1 $script"
    (procedure "critcl::collect" line 3)
    invoked from within
"critcl::collect $args"
    (procedure "get" line 2)
    invoked from within
"get critcl::cconst the::alpha bool 0"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $script"
---- errorCode: TCL LOOKUP COMMAND AbortWhenCalledAfterBuild
==== critcl-cconst-2.3 FAILED

Exit code

Hi,

How can a non zero exit code be obtained when a -pkg build fails?

Kind regards,

Jos.

build.tcl proc usage doesn't work on windows

If build.tcl is called on windows cmd line without args or even with the arg "help" it raises error.

Reason is in the (in both cases called) proc usage. This proc looks, if ::errorInfo exists and if yes, if it is empty. If it is not empty, the proc bailes out with [exit]ing the script.

Unfortunately, on windows, errorInfo isn't emtpy, after interp startup, because of a catch in init.tcl (tcl_pkgPath doesn't exist on windows).

Offer documentation in Html format?

I won't succeed in creating the Html format of the documentation:

$ /dtplite-1.0.3.tm -o ~/Projekte/git/critcl/doc/html html ~/Projekte/git/critcl/doc/

The error message is:

Unknown format "html"

When I try to give the format file instead of the keyword "html" to the command line:

$ dtplite-1.0.3.tm -o ~/Projekte/git/critcl/doc/html /home/dia/ActiveTcl-8.5/lib/teapot/package/tcl/lib/doctools1.4.13/mpformats/fmt.html ~/Projekte/git/critcl/doc/

The error message is:

doctools::toc::_configure: -format: /home/dia/ActiveTcl-8.5/lib/teapot/package/tcl/lib/doctools1.4.13/mpformats/fmt.html error: API incomplete, cannot use this engine

As I am complete new to doctools would it be possible to offer a html package in the doc/ folder?

./build.tcl starkit - fails on FreeBSD

I am trying to create some C extensions (sha256) with critcl to run on a FreeBSD system. I did

./build.tcl install

Installed package: /usr/local/lib/tcl8.5/critcl3
Installed package: /usr/local/lib/tcl8.5/critcl-util1
Installed package: /usr/local/lib/tcl8.5/critcl-app3
Installed package: /usr/local/lib/tcl8.5/util84 (dict84, lassign84 bundle)
Installed package: /usr/local/lib/tcl8.5/stubs (stubs::* bundle)
Installed application: /usr/local/bin/critcl

./build.tcl starkit

can't find package vfs::mk4
while executing
"package require vfs::mk4"
(procedure "_starkit" line 2)
invoked from within
"_starkit"
("eval" body line 1)
invoked from within
"eval _$argv"

I have tried to link tclsh to my tclkit-cli which I have just created with Github's kitgen and which has the vfs::mk4 inside but this fails, too.

The FreeBSD tclsh shows this lib configuration:

% set auto_path
/usr/local/lib/tcl8.5 /usr/local/lib
% info library
/usr/local/lib/tcl8.5

The tree of /usr/local/lib/tcl8.5 is:

|-- auto.tcl
|-- clock.tcl
|-- critcl-app3/
|-- critcl-app3.1/
|-- critcl-class1/
|-- critcl-util1/
|-- critcl3/
|-- critcl3.1/
|-- encoding/
|-- history.tcl
|-- http1.0/
|-- init.tcl
|-- msgs/
|-- opt0.4/
|-- package.tcl
|-- parray.tcl
|-- safe.tcl
|-- stubs/
|-- tclAppInit.c
|-- tclConfig.sh
|-- tclIndex
|-- tm.tcl
|-- tzdata/
|-- util84/
`-- word.tcl

On my Linux system (Slackware 13.37) all works fine.

So I should make a libvfs.so for FreeBSD?

Resetting the lines option to 0 still outputs #line directives

For debugging, it is helpful turning the off the source line linking (::critcl::config lines 0), and instead look at the generated C file. See http://wiki.tcl.tk/13214.

When turning this option off, critcl still generates some of the#line pragmas, making the result unusable. The sources of #line pragmas are at least the following:

  • Templates including the pragmas:

    lib/critcl-class/class.h:64:#line 65 "class.h"
    lib/critcl-class/class.h:77:#line 78 "class.h"
    lib/critcl-class/class.h:101:#line 102 "class.h"
    lib/critcl-class/class.h:131:#line 131 "class.h"
    lib/critcl-class/class.h:145:#line 145 "class.h"
    lib/critcl-class/class.h:155:#line 155 "class.h"
    lib/critcl-class/class.h:162:#line 162 "class.h"
    lib/critcl-class/class.h:321:#line 320 "class.h"
    lib/critcl-iassoc/iassoc.h:16:#line 17 "iassoc.h"
    lib/critcl-iassoc/iassoc.h:28:#line 29 "iassoc.h"
    lib/critcl-iassoc/iassoc.h:38:#line 39 "iassoc.h"
    lib/critcl/critcl_c/pkginittk.c:2:# line 1 "MyInitTkStubs"
    lib/critcl/critcl_c/stubs.c:2:# line 1 "MyInitTclStubs"
    lib/critcl/critcl_c/stubs_e.c:2:# line 1 "MyInitTclStubs"
    
  • Code generated upon Initialize. This procedure is invoked when requiring the package, so the configuration option has not had a chance of been reset before it runs.

One option would be guarding the #line directives by #if SHOW_LINES, and defining it to whatever the user has configured when compiling. What do you think?

critcl31.exe very slow on WIndows (starpack, not critcl issue I think)

I do not believe this is a critcl issue, but logging it FYI in case someone else also has a similar problem.

Using critcl31.exe on Windows seems to have quadratic behaviour on the size of the critcl input files. Using the standard package (also critcl 3.1) has no such issues - my input compiles within a couple of seconds. With critcl31.exe, it goes on for a couple of minutes with 100% cpu before I kill it.

I believe this is actually a starpack issue as I have seen similar behaviour with other starpacks on Windows (local disk, not network).

/Ashok

Disable md5 hashing in package mode (-pkg) as its object cache is unique and transient anyway

Reported by jbroll in the comments of #29:

 I haven't shown it yet but it seems that there must be
an unintended quadratic complexity somewhere. 

I suspected md5 as the issue, with missing C accelerator for it when used from the critcl starkit. John was able to confirm:

proc md5 { x } { return [expr rand()] } } 
This seems to work for my limited case ... Would it be possible
to disable the md5 hashing in this case [critcl -pkg, has its own
transient cache directory].

And I believe the answer is yes. This issue is created to track work on this.

Compiler warnings are not shown if compilation does not also produce errors

critcl shows the log if the build fails with an error. However, if the compiler/linker only generates warnings and not errors, the warnings are not shown at all. This can bite when the warnings (e.g. a prototype mismatch) is crucial.

Request: critcl should display warnings (without failing the compile) even when there are no fatal errors.

Patch forthcoming

Detecting MSVC version on a German Windows system

A German compiler installation gives German report messages, e.g. in my case (Visual C++ 2010 Express):

Microsoft (R) 32-Bit C/C++-Optimierungscompiler Version 16.00.40219.01 f�ür 80x86

The regexp in critcl/Config is too restrictive to detect it. Reducing it from

regexp {Compiler Version ([0-9.]*) for} $output -> msvcversion

to

regexp {Version ([0-9.]*) } $output -> msvcversion

makes it work (again: in Germany; I don't know if Version is a reliable prefix to test for).

build.tcl fails

When running build.tcl without arguments I get the following error:

can't read "errorInfo": no such variable
    while executing
"if {($errorInfo ne {}) &&
    ![string match {invalid command name "_*"*} $errorInfo]
    } {
    puts stderr $::errorInfo
    exit
    }"
    (procedure "usage" line 3)
    invoked from within
"usage 0"
    (procedure "_help" line 2)
    invoked from within
"_help"
    ("eval" body line 1)
    invoked from within
"eval _$argv"

Possible patch: check if errorInfo exists

proc usage {{status 1}} {
    global errorInfo
    if {[info exists $errorInfo] && ($errorInfo ne {}) &&
    ![string match {invalid command name "_*"*} $errorInfo]
    } {
    puts stderr $::errorInfo
    exit
    }
    ...

issue with compile on win 7 64

I use visual studio 9 and critcl3
I try to create a package with this line:
tclsh critcl3.kit -pkg base64 base64\base64.tcl

upon linking I get the following error:
link
-nologo
-release
-opt:ref
-opt:icf,3
-ws:aggressive
-verbose:lib
$msvcbufferoverflowU.lib
-dll
-out:C:/Users/emet/.critcl/pkg32216.1444382408/v307_01bb8f5e3fbd9a66ef04
fb55e3bfdcc8.dll
@C:/Users/emet/.critcl/pkg32216.1444382408/link.fil

ERROR while linking C:/Users/emet/.critcl/pkg32216.1444382408/v307_01bb8f5e3fbd9
a66ef04fb55e3bfdcc8.dll:
LINK : warning LNK4044: unrecognized option '/ws:aggressive'; ignored
LINK : fatal error LNK1181: cannot open input file '$msvcbufferoverflowU.lib'
child process exited abnormally
Manifest Command: mt -manifest [list $outfile].manifest -outputresource:[list $o
utfile];2
Manifest File: <>, ignored

critcl build failed (D:/creditGuard/ashrait/tcllibc/base.dll)
(FAILED) Files left in C:/Users/emet/.critcl/pkg32216.1444382408
FAILURES 1
FAILED: <>
FAILED

The same code works fine with visual studio 6 on a 32 bits system.

the compile use this config:

cl
-nologo
-c
-DUSE_THREAD_ALLOC=1
-D_REENTRANT=1
-D_THREAD_SAFE=1
-DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1
-DHAVE_READDIR_R=1
-DTCL_THREADS=1
-DUSE_TCL_STUBS
-IC:/Users/emet/.critcl/pkg32216.1444382408/tcl8.4
-IC:/Users/emet/.critcl/pkg32216.1444382408
-FoC:/Users/emet/.critcl/pkg32216.1444382408/v307_01bb8f5e3fbd9a66ef04fb
55e3bfdcc8_pic.obj
C:/Users/emet/.critcl/pkg32216.1444382408/v307_01bb8f5e3fbd9a66ef04fb55e
3bfdcc8.c
-W3
-O2
-Op
-Gs
-MD
-DNDEBUG

cl : Command line warning D9002 : ignoring unknown option '-Op'

cdefines failes if ccode block includes a file.

If the critcl file contains:

critcl::cheaders tna.h tna-register.h tpool/tpool.h
critcl::cdefines TNA_TYPE_* tna

Then :

critcl -target macosx-x86_32 -force -pkg tna
Compilation forced
Config: macosx-x86_32
Build: macosx-ix86-gcc
Target: macosx-x86_32
Source: tna.tcl (provide tna 0.5)tna.tcl:124:75: error: tna.h: No such file or directory
tna.tcl:125:20: error: tpool.h: No such file or directory
while executing
"close $pipe"
(procedure "BuildDefines" line 57)
invoked from within
"BuildDefines $fd $file"
(procedure "CollectEmbeddedSources" line 65)
invoked from within
"CollectEmbeddedSources $file $base.c $object $initname $placestubs"
(procedure "critcl::cbuild" line 38)
invoked from within
"critcl::cbuild $fn 0"
(procedure "ProcessInput" line 181)
invoked from within
"ProcessInput"
(procedure "critcl::app::main" line 13)
invoked from within
"critcl::app::main $argv"
(file "/Users/john/bin/critcl" line 5)
make: *** [lib/tna/macosx-ix86/tna.dylib] Error 1

Perhaps this happens because in the tna.tcl file I must include the tpool.h file directly, not from the subdirectory to satisfy the files copied for the compiler environment. The cdefines isn't run from the same directory file set up but tries to follow the #include statements in my ccode blocks.

If I change the cheaders directive to :

critcl::cheaders tna.h tna-register.h

Now it complaines about not finding "tna.h" so the issues is not related to the subdirectory but just in chasing down "#include"s in the ccode block.

Thanks,

John

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.