I'm trying to build GNU COBOL with VS 2019 but the instructions in README aren't precise - I managed to compile changing projects configurations (I messed up output with pre-requisites!) but I wish it would be as easy as in linux.
Someone can help me understanding the instruction so I can write a noob's guide?
FWIW I'm chasing a stable way to use 3.1.2 + Windows (32 & 64) + DB2
Regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You potentially want to just grab the binaries from the nightly CI (3.x is considered more stable than 3.1.2), if not then I guess you've downloaded the official source zip, unpacked it and worked your way through build_windows\README.txt, correct?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes. Actually that is 3.2 and you can even see it in the executables' properties (side note: the resource files are likely to be used in the future for MinGW, too, I've just not took the time to do this, but it would be good to to it before 3.2 final).
The reason it is 3.1.1-dev is that build_windows/config.h.in is outdated.
With the next commit there I'll likely fix that, it is just too minor to commit and redo the builds for that...
/* Version number of package */
-#define VERSION "3.2-dev"+#define VERSION "3.2-dev"
or 3.2 and 4 are being developed in a private branches?
3.2 is developed in the gnucobol-3.x branch, 4.0 is the main point of new developments: it is in "trunk" (you can browse or download the code in the top navigation under "code", if you want to investigate things deeper it would be reasonable to use svn to interact with it, on Win32 I can recommend TortoiseSVN to do so).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sergio, about a year ago I did quite a bit of testing with Windows / GNUCOBOL / DB2 to get a working environment. I had the most success using the 64 bit Visual Studio version of the compiler. I also used the CI builds which Simon referenced in his reply below this for the VS builds and Arnold's MinGW prebuilt builds. See the following link which explains the testing I did earlier. Perhaps some of the issues I faced have been resolved with the evolution of the GNUCOBOL compiler.
You search for -A '-I "D:\DB2\SQLLIB\include" --include sqlaprep.h' (GCC) or -A '/I "D:\DB2\SQLLIB\include" /FI sqlaprep.h' (VC).
Using the correct prototypes very often helps, but they are commonly only used when you use CALL STATIC (or otherwise specify a CALL-CONVENTION that includes static linking) - and in this case you likely want to disable cobc's own generation of the prototypes by -fno-gen-c-decl-static-call.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the information Simon, I will give those a try. I'm waiting to see if Sergio wants to collaborate on some testing with DB2.
It is a bit frustrating that embedded SQL with DB2 & precompiler does not seem to work consistently with different builds of GNUCOBOL. I should note that I never use MinGW builds in a MinGW environment, only in a Windows 10 command prompt. I've not heard an explanation as to whether the MinGW builds behave differently between a Windows command prompt or a MinGW environment.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've not heard an explanation as to whether the MinGW builds behave differently between a Windows command prompt or a MinGW environment.
As long as the same environment variables are set up there's only a difference in wildcard handling of files. As soon as cobc (or a COBOL program) runs - there is no difference any more.
The most important thing here is to ensure that you use 32bit libraries for 32bit builds and 64bit libraries for 64bit builds, passing the correct library and include paths to cobc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Simon, I tried the above with VS2019 64 bit compiler downloaded from the AppVeyor and the -A option would not work with single quotes. It did work successfully with double quotes.
It took me a while to figure out why it was failing, perhaps this will save someone a bit of time if they need to pass parms to the MSVC compiler.
I'm ignoring the STDCALL warnings as I'm attempting to use the output of the IBM DB2 PRECOMPILER without changing the output of the precompiler. I do modify the value of the DB2API in the SPECIAL-NAMES paragraph to have a value of 64 instead of the generated value of 74. This allows me to control the static / dynamic calls via a compiler option rather than having it hard coded.
Last edit: Chuck Haatvedt 2021-09-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the -A option would not work with single quotes. It did work successfully with double quotes.
Yes, that's a cmd.exe issue (may work from PowerShell, works from any posix-shell).
Using single quotes commonly ensures the option is taken "as-is" and also allows to easily use double quotes without escape sequences.
I'm ignoring the STDCALL warnings as I'm attempting to use the output of the IBM DB2 PRECOMPILER without changing the output of the precompiler. I do modify the value of the DB2API in the SPECIAL-NAMES paragraph to have a value of 64 instead of the generated value of 74.
In this case it seems reasonable to drop the STDCALL bit from it, too, isn't it?
Note:
ignoring SYNCHRONIZED for group item 'SQLCA' [-Wadditional]
Could point to a potential problem, I think it expects all entries in the group to be synchronized, and if this isn't the case that definitely could change the result.
At least something to watch out for...
You may suppress the C warnings by adding that to -Aafter checking them once!, for GCC this would be -Wno-strict-aliasing, for VC this seems to be /wd4133.
For the check: use the same command line but the following instead of the COBOL source:
#include<stdio.h>intmain(){printf("\nSize of sqlca: %d",sizeof(structsqlca));return0;}
if that outputs 136 then there's at least less to be worried about.
Last edit: Simon Sobisch 2021-09-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-09-01
If you are interested, I would be willing to work on this with you.
Yes, I'm but have very few available time :(
I will back to this next weekend and at least compile some "Hello world" DB2 program.
FWIW I have latest DB2 11.5.x installed in Windows 10 and Ubuntu 20.04 running on WSL.
Regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sergio, I'm assuming that this is your reply and that you forgot to login.
I also have DB2 11.5.x installed on Windows 10. I do have a dual boot system with Opensuse Tumbleweed and Windows 10, however I prefer to work on Windows as my knowledge of Linux is very minimal. I also have the Visual Studio 2019 Community Edition installed.
There have been some new CI builds for the VS2019 builds recently. I will download the most recent builds to test them in the next few days. I'll test with both the 64 & 32 bit builds. I have downloaded the MSYS2 builds from Arnold's site as it seems like MinGW MSYS2 is a more current environment. However Arnold's builds are not as current as the CI builds, if we encounter issues which may be related to the age of Arnold's builds, we could attempt to follow the build instructions on Arnold's website.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have installed both the 32 bit and 64 bit Visual Studio 2019 builds from the CI site. So I'm ready to start testing. I have been testing with the sample COBOL programs included with the DB2 11.5 installation.
If you could send me a messsage via SourceForge, I can respond with my personal email address. That way we could correspond directly until we complete out testing. Then we could post our results to the discussion here.
Chuck Haatvedt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm trying to build GNU COBOL with VS 2019 but the instructions in README aren't precise - I managed to compile changing projects configurations (I messed up output with pre-requisites!) but I wish it would be as easy as in linux.
Someone can help me understanding the instruction so I can write a noob's guide?
FWIW I'm chasing a stable way to use 3.1.2 + Windows (32 & 64) + DB2
Regards!
You potentially want to just grab the binaries from the nightly CI (3.x is considered more stable than 3.1.2), if not then I guess you've downloaded the official source zip, unpacked it and worked your way through build_windows\README.txt, correct?
Hi Simon, thanks for your quick response.
For my current objective that may be better than struggling building it
Is possible to do that? If so, were I can grab it?
Yep, that's what I did and since I'm not C dev I have been spending time figuring out to build it instead of actually testing DB2's programs.
Last edit: Sergio Samayoa 2021-08-30
Never mind, I just found it following the link on another post:
https://ci.appveyor.com/project/GitMensch/gnucobol-3-x-vs
BTW why is 3.1.1-dev?
Shouldn't be 3.2? or 3.2 and 4 are being developed in a private branches?
Regards!
Last edit: Sergio Samayoa 2021-08-30
Yes. Actually that is 3.2 and you can even see it in the executables' properties (side note: the resource files are likely to be used in the future for MinGW, too, I've just not took the time to do this, but it would be good to to it before 3.2 final).
The reason it is 3.1.1-dev is that build_windows/config.h.in is outdated.
With the next commit there I'll likely fix that, it is just too minor to commit and redo the builds for that...
3.2 is developed in the gnucobol-3.x branch, 4.0 is the main point of new developments: it is in "trunk" (you can browse or download the code in the top navigation under "code", if you want to investigate things deeper it would be reasonable to use
svnto interact with it, on Win32 I can recommend TortoiseSVN to do so).Sergio, about a year ago I did quite a bit of testing with Windows / GNUCOBOL / DB2 to get a working environment. I had the most success using the 64 bit Visual Studio version of the compiler. I also used the CI builds which Simon referenced in his reply below this for the VS builds and Arnold's MinGW prebuilt builds. See the following link which explains the testing I did earlier. Perhaps some of the issues I faced have been resolved with the evolution of the GNUCOBOL compiler.
https://sourceforge.net/p/gnucobol/bugs/673/#14ab/3e7b
Later I did find where the prototypes for the C call functions are for the DB2 modules, they are in this member
D:\DB2\SQLLIB\include\sqlaprep.h
However, I was not quite sure how to get that include header to be used by the C compiler when invoking COBC.
If you are interested, I would be willing to work on this with you.
Chuck Haatvedt
Last edit: Simon Sobisch 2021-08-31
You search for
-A '-I "D:\DB2\SQLLIB\include" --include sqlaprep.h'(GCC) or-A '/I "D:\DB2\SQLLIB\include" /FI sqlaprep.h'(VC).Using the correct prototypes very often helps, but they are commonly only used when you use
CALL STATIC(or otherwise specify aCALL-CONVENTIONthat includes static linking) - and in this case you likely want to disable cobc's own generation of the prototypes by-fno-gen-c-decl-static-call.Thanks for the information Simon, I will give those a try. I'm waiting to see if Sergio wants to collaborate on some testing with DB2.
It is a bit frustrating that embedded SQL with DB2 & precompiler does not seem to work consistently with different builds of GNUCOBOL. I should note that I never use MinGW builds in a MinGW environment, only in a Windows 10 command prompt. I've not heard an explanation as to whether the MinGW builds behave differently between a Windows command prompt or a MinGW environment.
As long as the same environment variables are set up there's only a difference in wildcard handling of files. As soon as
cobc(or a COBOL program) runs - there is no difference any more.The most important thing here is to ensure that you use 32bit libraries for 32bit builds and 64bit libraries for 64bit builds, passing the correct library and include paths to cobc.
Simon, I tried the above with VS2019 64 bit compiler downloaded from the AppVeyor and the -A option would not work with single quotes. It did work successfully with double quotes.
It took me a while to figure out why it was failing, perhaps this will save someone a bit of time if they need to pass parms to the MSVC compiler.
I'm ignoring the STDCALL warnings as I'm attempting to use the output of the IBM DB2 PRECOMPILER without changing the output of the precompiler. I do modify the value of the DB2API in the SPECIAL-NAMES paragraph to have a value of 64 instead of the generated value of 74. This allows me to control the static / dynamic calls via a compiler option rather than having it hard coded.
Last edit: Chuck Haatvedt 2021-09-26
Yes, that's a cmd.exe issue (may work from PowerShell, works from any posix-shell).
Using single quotes commonly ensures the option is taken "as-is" and also allows to easily use double quotes without escape sequences.
In this case it seems reasonable to drop the STDCALL bit from it, too, isn't it?
Note:
Could point to a potential problem, I think it expects all entries in the group to be synchronized, and if this isn't the case that definitely could change the result.
At least something to watch out for...
You may suppress the C warnings by adding that to
-Aafter checking them once!, for GCC this would be-Wno-strict-aliasing, for VC this seems to be/wd4133.For the check: use the same command line but the following instead of the COBOL source:
if that outputs 136 then there's at least less to be worried about.
Last edit: Simon Sobisch 2021-09-28
Yes, I'm but have very few available time :(
I will back to this next weekend and at least compile some "Hello world" DB2 program.
FWIW I have latest DB2 11.5.x installed in Windows 10 and Ubuntu 20.04 running on WSL.
Regards!
Sergio, I'm assuming that this is your reply and that you forgot to login.
I also have DB2 11.5.x installed on Windows 10. I do have a dual boot system with Opensuse Tumbleweed and Windows 10, however I prefer to work on Windows as my knowledge of Linux is very minimal. I also have the Visual Studio 2019 Community Edition installed.
There have been some new CI builds for the VS2019 builds recently. I will download the most recent builds to test them in the next few days. I'll test with both the 64 & 32 bit builds. I have downloaded the MSYS2 builds from Arnold's site as it seems like MinGW MSYS2 is a more current environment. However Arnold's builds are not as current as the CI builds, if we encounter issues which may be related to the age of Arnold's builds, we could attempt to follow the build instructions on Arnold's website.
Sergio,
I have installed both the 32 bit and 64 bit Visual Studio 2019 builds from the CI site. So I'm ready to start testing. I have been testing with the sample COBOL programs included with the DB2 11.5 installation.
If you could send me a messsage via SourceForge, I can respond with my personal email address. That way we could correspond directly until we complete out testing. Then we could post our results to the discussion here.
Chuck Haatvedt
Just to recheck: you have both a 32bit and 64bit DB2 client sql library installed? Otherwise you can only test one of both environments.