Linkage issues with 3.2, works on 3.1.2

[A Delosa]

Hello team!

Have just got back to working on my COBOL project after a break (life got in the way) and noticed a new release! Fantastic!

The new version seems to be causing some grief to me with regards to linkage passing..

Error I am receiving in GnuCOBOL 3.2 is LINKAGE item <Linkage item name> not passed by caller

I reverted back to 3.1.2 and the app starts working again..it's part of a larger codebase so will need to do some digging to isolate the specific condition causing the issue.

This is not a new topic for me.. See https://sourceforge.net/p/gnucobol/discussion/help/thread/7ce4211af8/
The previous message I was getting was LINKAGE item 'LINKAGE2' (accessed by 'LINKAGE2-DATA') not passed by caller Seems like a similar issue, but the example that I created on GitHub to recreate my previous issue works fine with both versions so it must be something else.

Just want to see if there have been any changes in this area and if so, what should I be looking out for or focusing on.

Thanks
Anthony

[Simon Sobisch]

Hm, so is the module which raises this message still a COBOL modules that was called by COBOL? If this is the case - do you explicit set the number of parameters and ensured that the parameter for LINKAGE2 is non-NULL?
If you checkout the NEWS file, then you'll see that there were a bunch of changes around the check for parameters, for example by default with --debug/ -fec=program the caller's length is now checked, too.... and I'm quite sure that this would not work the way the original C code was done...

If you know the data is compatible and passed where necessary you can also add -fno-ec=PROGRAM-ARG-MISTMATCH to the compile of the (C)-called program - or adjust the called program to specify in its called ENTRY/ PROCEDURE DIVISION to specify a C calling convention.

[A Delosa]

Thanks for the response Simon. I was able to get the app running on the new version.

So in my app, its always C then COBOL then C then COBOL.. Never COBOL to COBOL.. The C programs allocates memory in a shared area and passes references to that memory area via linkage when calling the COBOL program.

I added the -fno-ec=PROGRAM-ARG-MISTMATCH (is that a typo?? MIS_T_MATCH) to the COBOL module compile and it now successfully running.

I am getting some warning in the COBOL build that I don't get without the flag above enabled.
Looks like MOVE statement to my linkage area causes the issue. Not sure if that is intentional or not, or if means there is some issue with my code.

In function ‘memcpy’,
    inlined from ‘X705074T_’ at X705074T.c:373:5:
/usr/include/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ offset [0, 2] is out of the bounds [0, 0] [-Warray-bounds=]
   29 |   return __builtin___memcpy_chk (__dest, __src, __len,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   30 |                                  __glibc_objsize0 (__dest));
      |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~

c generated code

    /* Line: 124       : MOVE               : X705074T.cob */
#line 124 "X705074T.cob"
    module->statement = STMT_MOVE;
#line 371 "X705074T.c"
    module->module_stmt = 0x0010007C;
    cob_check_linkage (b_125, "'X705074-APP-DATAGROUP' (accessed by 'X074-APP-ACTION')", 1);
    memcpy (b_125 + 4, "ADD", 3);

Cobol code

MOVE 'ADD' TO X074-APP-ACTION

Thanks again!
Anthony

[Simon Sobisch]

How is that variable defined in COBOL?

[A Delosa]

10 X074-APP-ACTION PIC XXX.

[A Delosa]

Another thing I have observed - this is on MacOS with ld version 1022.1 (latest)
I get a warning when using cobc command..
ld: warning: -undefined suppress is deprecated
It seems that cobc adds the following param that is no longer supported by macos.
-undefined suppress

[Simon Sobisch]

Please add -v to your command line to check what is passed, then post that.

Question: Is this a build from source or a Homebrew one?

[A Delosa]

Yes, this is homebrew, not compiled from source.

cobc (GnuCOBOL) 3.2.0
Built     Jul 28 2023 18:42:18  Packaged  Jul 28 2023 17:02:56 UTC
C version "Apple LLVM 15.0.0 (clang-1500.0.40.1)"
loading standard configuration file 'default.conf'
command line:   cobc -m -v -d -flisting-statements=ok -I/projects/this/include -Wno-goto-section -o /projects/this/lib/MODULE.dylib /projects/this/MODULE.cob 
preprocessing:  /projects/this/MODULE.cob -> /var/folders/k1/ly3xk9nx76d6vlddwb78n1km0000gn/T/cob18886_0.cob
return status:  0
parsing:        /var/folders/k1/ly3xk9nx76d6vlddwb78n1km0000gn/T/cob18886_0.cob (/projects/this/MODULE.cob)
return status:  0
translating:    /var/folders/k1/ly3xk9nx76d6vlddwb78n1km0000gn/T/cob18886_0.cob -> /var/folders/k1/ly3xk9nx76d6vlddwb78n1km0000gn/T/cob18886_0.c (/projects/this/MODULE.cob)
executing:      clang -pipe -I/opt/homebrew/Cellar/gmp/6.3.0/include
                -I/opt/homebrew/Cellar/gnucobol/3.2/include -Wno-unused
                -fsigned-char -Wno-pointer-sign -Qunused-arguments
                -Wno-deprecated-non-prototype
                -I"/projects/this/include"
                -bundle -flat_namespace -undefined suppress -fno-common -DPIC
                -o
                "/projects/this/lib/MODULE.dylib"
                "/var/folders/k1/ly3xk9nx76d6vlddwb78n1km0000gn/T/cob18886_0.c"
                -L/opt/homebrew/Cellar/gnucobol/3.2/lib -lcob
ld: warning: -undefined suppress is deprecated
ld: warning: -undefined suppress is deprecated
return status:  0

[Simon Sobisch]

That's a build/packaging issue, you possibly want to report that at https://github.com/Homebrew/homebrew-core/issues ; in any case you may want to ask brew to build it on your machine:

brew install --build-from-source gnucobol

then check if there's any difference.