mainGnuCOBOL (formerly OpenCOBOL) - Support: sr #110233, Rasied Call sr #109186 under Cobol...

 
 

sr #110233: Rasied Call sr #109186 under Cobol for GCC group in error

Submitter:  Paul Mitchell <pmitch1865>
Submitted:  Thu 07 May 2020 07:53:24 AM UTC
   
 
Category:  None Priority:  7 - High
Severity:  3 - Normal Status:  Duplicate
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  None

Discussion locked!

Thu 07 May 2020 07:53:24 AM UTC, comment #3: 

This item has been reassigned from the project GnuCOBOL (formerly OpenCOBOL) patch tracker to your tracker.

The original report is still available at patch #9168

Following are the information included in the original report:

[field #0]                  Item ID: 9168

[field #1]                 Group ID: 11215

[field #2]              Open/Closed: Closed

[field #3]                 Severity: 3 - Normal

[field #4]                  Privacy: Public

[field #8]                         : Unknown patch Field Display Type

[field #9]                 Category: None

[field #10]             Submitted by: pmitch1865

[field #11]              Assigned to: None

[field #12]             Submitted on: Mon 21 Nov 2016 02:59:16 PM CET

[field #13]                  Summary: Rasied Call sr #109186 under Cobol for GCC group in error

[field #14]      Original Submission: Rasied Call sr #109186 under Cobol for GCC group in error.

I should have created in this group.

Are you able to review this call under the about group and reassign to this group or do i need to raise this call as a new call under this group?

[field #16]               Item Group: None

[field #17]                   Status: Duplicate

[field #18]        Component Version: None

[field #19]         Operating System: None

[field #20]          Reproducibility: None

[field #21]               Size (loc): None

[field #22]            Fixed Release: None

[field #23]          Planned Release: None

[field #24]                   Effort: 0.00

[field #28]                 Priority: 7 - High

[field #31]         Percent Complete: 0%

[field #33]                  Release: None

[field #58]     Custom Select Box #1: None

[field #59]     Custom Select Box #2: None

[field #60]     Custom Select Box #3: None

[field #61]     Custom Select Box #4: None

[field #62]     Custom Select Box #5: None

[field #63]     Custom Select Box #6: None

[field #64]     Custom Select Box #7: None

[field #65]     Custom Select Box #8: None

[field #66]     Custom Select Box #9: None

[field #67]    Custom Select Box #10: None


Simon Sobisch <mensch>
Group administrator
Wed 30 Nov 2016 04:19:46 PM UTC, comment #2: 

Hi

I am desperate for some assistance on this issue.

Has anybody had a chance to review it?

Paul.

Paul Mitchell <pmitch1865>
Mon 21 Nov 2016 02:04:06 PM UTC, comment #1: 

This is the call content.

We need to be able to use an archive library due to access sub modules due its flexibility of control. However when trying to link a .a file we get the error.

libcob: cannot find module 'TEST_SUB'

We have compiled many binary object files and placed them into an archive library.
We have also compiled an executable module and as part of that compilation have attempted to link the previously mentioned archive library.
However on execution the executable module is not able to find a required binary object file located in the archive library.
It would appear that the archive library library is not in fact linked to the executable.
Could you provide guidance on how this is achieved within GNU Cobol.
Example would be
executable = TESTPROG
ar library = testlib.a
bin object = testobj.o
TESTPROG needs to call testobj.o and therefore testlib.a needs to be linked to TESTPROG.

In order to further assist with this i have created a test scenario.
This issue appears to be that no matter what i do to link a dynamically loadable module held within an archive library will allow that module to be dynamically located.
I always end up with the following error.
libcob: cannot find module
i have uploaded two files, TEST_CALL.cob (executable module) and TEST_SUB.cob (loadable module).
If you follow the process below to compile and run under a Linux environment you should receive the same result. If however you extract the TEST_SUB.so file from the library and and link directly to the file it will work.
TEST_SUB eg
------------
cobc -foptional-file -freserved=COMMAND-LINE -std=mf -m TEST_SUB.cob
ar -qv /stage/pmtest/libpmtst.a ./TEST_SUB.so
export LD_LIBRARY_PATH=/stage/pmtest
export COB_LIBRARY_PATH=/stage/pmtest
rm ./TEST_SUB.so
TEST_CALL eg
------------
cobc -v -x -foptional-file -std=mf -freserved=COMMAND-LINE -o TEST_CALL TEST_CALL.cob -L /stage/pmtest -lpmtst
env |grep pmtest
COB_LIBRARY_PATH=/stage/pmtest
LD_LIBRARY_PATH=/stage/pmtest
./TEST_CALL
libcob: cannot find module 'TEST_SUB'

Paul Mitchell <pmitch1865>
Thu 07 May 2020 07:53:24 AM UTC, original submission:  

Rasied Call sr #109186 under Cobol for GCC group in error.

I should have created in this group.

Are you able to review this call under the about group and reassign to this group or do i need to raise this call as a new call under this group?

Paul Mitchell <pmitch1865>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #39038:  TEST_CALL.cob added by pmitch1865 (546B - application/octet-stream)
file #39039:  TEST_SUB.cob added by pmitch1865 (408B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mensch (Updated the item)
  • -email is unavailable- added by pmitch1865 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-07 mensch Discussion LockNone Locked
    2020-05-07 mensch StatusNone Duplicate
        Open/ClosedOpen Closed
    2020-05-07 mensch Reassign itemGnuCOBOL (formerly OpenCOBOL), patch #9168 GnuCOBOL (formerly OpenCOBOL), sr #110233

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code