Patrick, Michael;
Yeah, this looks worth looking into. I'll try and snag a Mint stick
and run some tracer rounds.
strace can really help here.
Patrick, yeah, the terminal listing you sent me was incomplete, as my
instructions were wrong. Michael, you might try this too. At a
glance it doesn't look you are doing anything wrong.
After a build, run
$ strace programname
It'll spew a lot. The system calls. Look for failed opens, they
bunch up as search paths are traversed. Finding those lines can
usually lead to finding what path setting is wrong, or, can show low
level failures that aren't thrown up the chain to OpenCOBOL causing
funky failures of the stack frames. After that it becomes time to
look to COB_PRE_LOAD and the various LIBRARY_PATH options.
LD_LIBRARY_PATH, COB_LIBRARY_PATH
Cheers,
Brian
On 8/9/13, Michael Anderson <address@hidden> wrote:
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.