Re: [open-cobol-list] Linux Mint Borked?

[Michael Anderson]

Having the same problem as Patrick explained, and for now only with OpenCobol, not an issue with gcc linking.

I'm using:
cobc (OpenCOBOL CE) 1.1.0
Copyright (C) 2001-2009 Keisuke Nishida / Roger While
Built    Feb 08 2013 18:29:22
Packaged Feb 06 2009 10:30:55 CET

This did not link correctly, same logic written in C links correctly using the same '-ltcl' library reference..
cobc -x -ffunctions-all -free  myapp.cob -ltcl

./myapp
libcob: Cannot find module 'Tcl_FindExecutable'

So this seemed to do the trick: -fstatic-call
NOTE: -fstatic-call is Undocumented, NOT listed in 'cobc -h' output, and not in the OC pdf manual.

cobc -x -ffunctions-all -free  myapp.cob -fstatic-call -ltcl

So using -fstatic-call, works, the ldd output shows libtcl8.5.so.0, without -fstatic-call it is NOT in the ldd output:
$ ldd myapp
    linux-gate.so.1 =>  (0xb77bc000)
    libcob.so.1 => /usr/local/lib/libcob.so.1 (0xb776a000)
    libtcl8.5.so.0 => /usr/local/lib/libtcl8.5.so.0 (0xb7650000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb74a6000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb747a000)
    libgmp.so.10 => /usr/lib/i386-linux-gnu/libgmp.so.10 (0xb73fb000)
    libncurses.so.5 => /lib/i386-linux-gnu/libncurses.so.5 (0xb73d9000)
    libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb73ba000)
    libdb-5.1.so => /usr/lib/i386-linux-gnu/libdb-5.1.so (0xb7231000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb722c000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7211000)
    /lib/ld-linux.so.2 (0xb77bd000)

--fstatic-call indicates non-dynamic link,
However, "libtcl8.5.so.0 => /usr/local/lib/libtcl8.5.so.0" makes me thing dynamic.

So, -fstatic-call is referring to the dynamic/static function (SUB-PROGRAM) name verses the dynamic/static linking?
Therefore, the generated C code is different:

With -fstatic-call: Works

	(*(unsigned char **) (b_29)) = Tcl_FindExecutable ();

Without -fstatic-cal: Does Not Work

      	func = cob_resolve_1 ((const char *)"Tcl_FindExecutable");
      	(*(unsigned char **) (b_29)) = func ();

Without -fstatic-call 'cob_resolve_1' is being called, so how do I make 'cob_resolve_1' work right?
Or, should always use -fstatic-call, and if so should it be the default.
What the heck am I doing wrong.

--
Mike.



On 07/03/2013 10:05 PM, Patrick wrote:

Thanks Brian and thanks again Mike

I am still trying to piece together what went wrong  but it looks like things started to go bad on Mint Linux when I tried to embed Jim Tcl(a tiny Tcl implementation) and used this command cobc -x jim.cob -ljim .

It failed and then I tried Brain's cobpy.cob program and it failed too, only it was my mistake as I used a -lpython flag instead of a -lpython2.7 flag.

I made other mistakes as well.

Now that I am on Debian, cobc -x jim.cob -ljim works just fine. I think it's jim on Mint that may be borked and what caused me to go off on a tangent.

Thanks again for all your support.

I am really happy tonight, I have jim working well with Cobol. I want to tidy up some examples and then share.

Jim Tcl is used in a similar way to Lua but Lua has much more market share.

I think jim may be better suited for working with Cobol then Lua. Lua numbs the pain of working in C but with Cobol we just don't have the same kind of pain and I don't personally need Lua right now.

The main weak points I have seen and heard about with Lua are the module system, suitability for shell scripting and regular expressions.

Jim is not nearly as powerful or fast as Lua but with jim these 3 topics appear strong and are what I think will add benefit to Cobol. There is a great deal of overlap between the strengths of Cobol and Lua.

I will be back with my results soon, I hope I will have something that will be of help to someone else on the list.