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

[Brian Tiffin]

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