[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Anderson
Subject: Re: [open-cobol-list] Linux Mint Borked?
Date: Tue, 13 Aug 2013 08:06:55 -0500
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8

Thanks Brian, however, I am using Ubuntu 12.04, so it is not only a Mint issue.

I think "cob_resolve_1" is key to resolving the problem, when used, libcob fails to resolve dynamic link dependencies.

I'm going to attach three files here.

myapp.cob,         a small Cobol source file.
with-fstatic-call.txt, strace output where the -fstatic-call compile option was used. without-fstatic-call.txt, strace output where the -fstatic-call compile option was NOT used.

Without -fstatic-call, the myapp executable fails:
libcob: Cannot find module 'Tcl_FindExecutable'

My work-around is to always use -fstatic-call, however I am curious.

Thanks again,

PS: strace files generated like so:

cobc -x -fstatic-call -ffunctions-all -free myapp.cob -ltcl
strace ./myapp 2>&1|cat > with-fstatic-call.txt

cobc -x -ffunctions-all -free myapp.cob -ltcl
strace ./myapp 2>&1|cat > without-fstatic-call.txt

On 08/12/2013 10:34 PM, Brian Tiffin wrote:
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.


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

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,
without -fstatic-call it is NOT in the ldd output:
$ ldd myapp =>  (0xb77bc000) => /usr/local/lib/ (0xb776a000) => /usr/local/lib/ (0xb7650000) => /lib/i386-linux-gnu/ (0xb74a6000) => /lib/i386-linux-gnu/ (0xb747a000) => /usr/lib/i386-linux-gnu/ (0xb73fb000) => /lib/i386-linux-gnu/ (0xb73d9000) => /lib/i386-linux-gnu/ (0xb73ba000) => /usr/lib/i386-linux-gnu/ (0xb7231000) => /lib/i386-linux-gnu/ (0xb722c000) => /lib/i386-linux-gnu/ (0xb7211000)
      /lib/ (0xb77bd000)

--fstatic-call indicates non-dynamic link,
However, " => /usr/local/lib/" 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.


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

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.

Attachment: without-fstatic-call.txt
Description: Text document

Attachment: with-fstatic-call.txt
Description: Text document

Attachment: myapp.cob
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]