So after successfully inplementing and making GNUCOBOL thanks to Simon on this forum... I've come accross an error when trying to run this command: (Please see below) Any assistance will be greatly appreciatred.....
As you may see from the output: there's no need to manually specify -I/path/to/libcob.h, -L/path/to/libcob, -lcob or -lm on the command line, cobc knows of this need and adds those where necessary (if you are interested cobc -v always tells you what it does, cobc --info will tell you about the inbuilt defaults that are automatically calculated when running the configure script).
Concerning the actual error: the linker is instructed to use BPAY2CALL (I guess this is directly referenced in bpay2chk.c and you want to use static C to COBOL. In the case of static calls everything needs to be available at link time and this includes correct casing. C seems to use BPAY2CALL and I'm quite sure that BPAY2CALL.o, presumably from a BPAY2CALL,cob does not provide this entry point. Possibly the PROGRAM-ID has a different casing?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the info. I'm not in the position to modify any of the programs listed. Im looking for an alternative to microfocus which works when this command is run (see below). The linker produces the final c routine. Cheers.
In this case adding -ffold-call=UPPER when creating BPAY2CALL .o should be a workaround (but this won't work without additional work if the COBOL programs call C entry points that are in lower-case or even C library functions, to be able to still use those a very small additional wrapper would be needed [one extra CENTRIES.o for the link]).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure about MF's cob compiler driver program, but with cobc you never should ever need to run the compiler itself - just feed cobc with everything and it (very likely ;-) does the correct thing.
That said cboc -x is for creating a "main" a "system executable file" (so same as MF). Those are used to directly call from the operating system, if you want to link this with other programs then only one of those may include the -x.
As the main program actually is bpay2chk.c I'd remove all -x from that scrip when converting it from cob to cobc and you should be good to go.
So I guess this means you've just reached the next step of the conversion test?
Side note: I've mod-edited your post to include "proper" syntax, please check via "edit" how it is done, allowing you to post even better ;-)
Last edit: Simon Sobisch 2020-10-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've wrapped single commands / identifiers in backticks ` and pieces of code or shell into a code area (starts and ends with ```) with a language hint.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those undefined entries are parts of either libcob or your libc. As the link loader should load both when the executable is run I think all is fine. Use ldd bpay2chkto check if all libraries referenced in the executable can be resolved.
If it can't and only libcob is an issue you possibly want to either add a linker realpath hint (what works and the way it needs to be specified is system dependent, could only look for online docs if/how to do this on hpux with the neative compiler/linker) or add /usr/local/lib to LD_LIBRARY_PATH.
Last edit: Simon Sobisch 2020-10-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
find library=libcob.so.4; required by bpay2chk
libcob.so.4 => /usr/local/lib/hpux64/libcob.so.4
find library=libm.so.1; required by bpay2chk
libm.so.1 => /usr/lib/hpux64/libm.so.1
find library=libc.so.1; required by bpay2chk
libc.so.1 => /usr/lib/hpux64/libc.so.1
find library=libm.so.1; required by /usr/local/lib/hpux64/libcob.so.4
libm.so.1 => /usr/lib/hpux64/libm.so.1
find library=/usr/local/lib/hpux64/libgmp.so; required by /usr/local/lib/hpux64/libcob.so.4
/usr/local/lib/hpux64/libgmp.so => /usr/local/lib/hpux64/libgmp.so
** '/usr/local/lib/hpux64/libgmp.so' is not a valid load module: Bad magic number**
Last edit: Mark Di Donato 2020-10-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've missed the "bad magic number part" before (guess it was post edited and I personally read the posts mainly via mail subscription) - How did you resolved it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, -fimplicit-init works around that. ut of interest: did you found that in the manual (HTML version linked above, but also shipped as PDF under "docs"), directly in the cobc --help or somewhere else?
Note: that option has not have any side-effect in 3.1 (it had it before, pimarily a minimal less startup time), the main reason that -fimplicit-init isn't implied is that by using this option COBOL modules won't have access to the command line (which you can also prohibit when explicit initializing the runtime) and that you must have an explicit STOP RUN in the COBOL modules, otherwise the runtime won't ever get a clear tear-down.
If you do that - no problem (but it won't allow the "C" part to do anyything after COBOL), otherwise I suggest to recheck if it would be possible to explicit initialize the runtime before the first COBOL invokation via cob_init and after COBOL has done its work tear it down via cob_tidy. The same would be true for MF-compilers (and libcob.h defines wrappers for the MF variant cobinit/cobtidy). You can do this in every part of the "C" side and also re-initialize to cleanly separate the COBOL parts, if that's reasonable (initializing and tear-down takes some cpu-cycles of course, so you likely don't want to do that 100times per minute).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, cobc --help makes mention of -fimplicit-init
Looking for another way to intitalise runtime without modifing code, is it possible to do this with an environment variable. Settings so far include:
No, that way you'd just have the minimal implicit init and you'd still have no explicit tear-down.
As mentioned: this is no issue as long as you don't need access to the command line options form COBOL, there's a guaranteed STOP RUN in the COBOL code called and there's nothing to do after the first call of a COBOL entry from C.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi everyone,
So after successfully inplementing and making GNUCOBOL thanks to Simon on this forum... I've come accross an error when trying to run this command: (Please see below)
Any assistance will be greatly appreciatred.....
Last edit: Simon Sobisch 2020-10-22
As you may see from the output: there's no need to manually specify
-I/path/to/libcob.h,-L/path/to/libcob,-lcobor-lmon the command line,cobcknows of this need and adds those where necessary (if you are interestedcobc -valways tells you what it does,cobc --infowill tell you about the inbuilt defaults that are automatically calculated when running the configure script).Concerning the actual error: the linker is instructed to use
BPAY2CALL(I guess this is directly referenced in bpay2chk.c and you want to use static C to COBOL. In the case of static calls everything needs to be available at link time and this includes correct casing. C seems to useBPAY2CALLand I'm quite sure that BPAY2CALL.o, presumably from a BPAY2CALL,cob does not provide this entry point. Possibly thePROGRAM-IDhas a different casing?Hi Simon,
Thanks for the info. I'm not in the position to modify any of the programs listed. Im looking for an alternative to microfocus which works when this command is run (see below). The linker produces the final c routine. Cheers.
/opt/microfocus/cobol/bin/cob -xU bpay2chk.c BPAY2CALL.o CCSVALCN.o CCSGENCD.o CCSINTCN.o -o bpay2chk
There are options to work around this. Is BPAY2CALL a COBOL program? If yes, how does its
PROGRAM-IDlook like?Hi Simon,
Here it is..
Last edit: Simon Sobisch 2020-10-22
In this case adding
-ffold-call=UPPERwhen creating BPAY2CALL .o should be a workaround (but this won't work without additional work if the COBOL programs call C entry points that are in lower-case or even C library functions, to be able to still use those a very small additional wrapper would be needed [one extra CENTRIES.o for the link]).Hi Simon
So here is my compile script:
Here is the output now:
Have known other to get it going in similar environments using:
Simon, please note the -cx (x =executable) for first 4 programs.
When I include the -cx the following errors occur.
Last edit: Simon Sobisch 2020-10-22
I'm not sure about MF's
cobcompiler driver program, but withcobcyou never should ever need to run the compiler itself - just feed cobc with everything and it (very likely ;-) does the correct thing.That said
cboc -xis for creating a "main" a "system executable file" (so same as MF). Those are used to directly call from the operating system, if you want to link this with other programs then only one of those may include the-x.As the main program actually is bpay2chk.c I'd remove all
-xfrom that scrip when converting it fromcobtocobcand you should be good to go.So I guess this means you've just reached the next step of the conversion test?
Side note: I've mod-edited your post to include "proper" syntax, please check via "edit" how it is done, allowing you to post even better ;-)
Last edit: Simon Sobisch 2020-10-22
Hi Simon,
I tried to use the edit function in my posts but I cannot identify what changes you have made to my posts.
Thanks
Mark.
I've wrapped single commands / identifiers in backticks ` and pieces of code or shell into a code area (starts and ends with ```) with a language hint.
Brillaint , thanks Simon.
Can I ask when I run:
nm bpay2chk - there are a lot of UNDEF strings, looks like I'm im missing libs. What do you think?
Thanks.
Last edit: Simon Sobisch 2020-10-22
Those undefined entries are parts of either libcob or your libc. As the link loader should load both when the executable is run I think all is fine. Use
ldd bpay2chkto check if all libraries referenced in the executable can be resolved.If it can't and only libcob is an issue you possibly want to either add a linker realpath hint (what works and the way it needs to be specified is system dependent, could only look for online docs if/how to do this on hpux with the neative compiler/linker) or add
/usr/local/libtoLD_LIBRARY_PATH.Last edit: Simon Sobisch 2020-10-22
Yep, they can.
however with: ldd -v bpay2chk I get this result:
ldd -v bpay2chk
bpay2chk:
find library=libcob.so.4; required by bpay2chk
libcob.so.4 => /usr/local/lib/hpux64/libcob.so.4
find library=libm.so.1; required by bpay2chk
libm.so.1 => /usr/lib/hpux64/libm.so.1
find library=libc.so.1; required by bpay2chk
libc.so.1 => /usr/lib/hpux64/libc.so.1
find library=libm.so.1; required by /usr/local/lib/hpux64/libcob.so.4
libm.so.1 => /usr/lib/hpux64/libm.so.1
find library=/usr/local/lib/hpux64/libgmp.so; required by /usr/local/lib/hpux64/libcob.so.4
/usr/local/lib/hpux64/libgmp.so => /usr/local/lib/hpux64/libgmp.so
** '/usr/local/lib/hpux64/libgmp.so' is not a valid load module: Bad magic number**
Last edit: Mark Di Donato 2020-10-22
Hi Simon,
Thanks for your help, I've resolved the Bad magic number error.... but when, I tested the program and I now receive the following erorr:
libcob: error: cob_init() has not been called
Is this this an issue with my environment setup/initialisation (at run time).
Thanks Simon
regards,
Mark.
Last edit: Mark Di Donato 2020-10-26
I've missed the "bad magic number part" before (guess it was post edited and I personally read the posts mainly via mail subscription) - How did you resolved it?
My bad here, accidently cleared the library... I had a backup... :)
Hi Simon,
Managed to solve the; libcob: error: cob_init() has not been called error
by adding the -fimplicit-init option to tmy cobc statements.
Fantastic Stuff!
Thanks
Mark.
Yes,
-fimplicit-initworks around that. ut of interest: did you found that in the manual (HTML version linked above, but also shipped as PDF under "docs"), directly in thecobc --helpor somewhere else?Note: that option has not have any side-effect in 3.1 (it had it before, pimarily a minimal less startup time), the main reason that
-fimplicit-initisn't implied is that by using this option COBOL modules won't have access to the command line (which you can also prohibit when explicit initializing the runtime) and that you must have an explicitSTOP RUNin the COBOL modules, otherwise the runtime won't ever get a clear tear-down.If you do that - no problem (but it won't allow the "C" part to do anyything after COBOL), otherwise I suggest to recheck if it would be possible to explicit initialize the runtime before the first COBOL invokation via
cob_initand after COBOL has done its work tear it down viacob_tidy. The same would be true for MF-compilers (and libcob.h defines wrappers for the MF variantcobinit/cobtidy). You can do this in every part of the "C" side and also re-initialize to cleanly separate the COBOL parts, if that's reasonable (initializing and tear-down takes some cpu-cycles of course, so you likely don't want to do that 100times per minute).Hi
Yes, cobc --help makes mention of -fimplicit-init
Looking for another way to intitalise runtime without modifing code, is it possible to do this with an environment variable. Settings so far include:
SHLIB_PATH=/usr/local/lib/hpux64:/usr/lib/hpux64
LD_LIBRARY_PATH=/usr/local/lib/hpux64:/usr/lib/hpux64
COB_LIBRARY_PATH=/usr/local/lib
Cheers.
No, that way you'd just have the minimal implicit init and you'd still have no explicit tear-down.
As mentioned: this is no issue as long as you don't need access to the command line options form COBOL, there's a guaranteed
STOP RUNin the COBOL code called and there's nothing to do after the first call of a COBOL entry from C.