@jklowden: I've edited your post to fix the link to the current gitea repo and included a link to the esqlOC place under contrib. I want to encourage you to do the later also in your repo's README and possibly switch your local contrib symlink to a getEsql.sh that places it in that folder + have it git.ignore'd.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, Simon. So far, my user count is 0 with a possibility of 1. As the work continues, if there's interest, I'll look for a better way to package it. Probably best is just to require esql be installed, and remove the symlink altogether.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you James K. Lowden, I will redo this example here, again, then I will pass on the result to you. I hope I don't have to configure anything, as I'm not good at doing that.
Celso Henrique
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're using a GCC based version, therefore you can drop the vcvarsall call. As -fixedis the default you also don't need to specify it on the command line. But in any case it is necessary to tell cobc to link against the library and where to found it. So this gives two possible command lines... and a possible third I did not thought about before:
The second one was a typo by me, should have been -locsql, for the third place a space after the -Q - and in all three cases: esnure that esqlOC_RUNTIME is set as you've previously did.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess both ways will work if you use a matching architecture - cobc --info likely reports itself as 32bit, doesn't it? In this case use the x86 directory of esqloc (or a 64bit version of cobc if you want to stick to x64).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One thing I find strange, is that, every time I go to DOS, I have to type the following command: " call "C: \ OpenCobolIDE \ GnuCOBOL \ set_env.cmd " ". what I have to do, so that I don’t have to type this command every time.
Celso Henrique.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
possibly break something in windows by bringing in some linux commands: setx PATH=C:\OpenCobolIDE\GnuCOBOL\bin;%PATH%
possibly break something in GnuCOBOL (if this is the case then you'd need to manually set it back via comptuer management -> environment variables and use the first main option): setx PATH=%PATH%;C:\OpenCobolIDE\GnuCOBOL\bin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm, no? Actually I've explicit added the 64bit-mode output to cobc --info to ease debugging of issues like that.
You're very likely (99%) running Win10 64bit with GnuCOBOL 32bit, which is not necessarily a bad setup btw. But you can only link against 32bit libs/dlls in this case (as I've said: no problem as the system has defined borders, mainly CALL 'SYSTEM'[another executable] and all IPC like socket, named-pipes, message queue, ... and ODBC [so your DB server may be 64bit]).
Just retry with the x86 setup for esqlOC and you're likely get further.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good to see that the linking works as expected now. Things to do next: add -debug -g to the command line and see if you get any different output with one of those commands.
And ensure that %esqlOC_RUNTIME% is in %PATH% when running this program.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These are the result of -g and needed for debugging in "C" (I think we can jsut ignore those). Do you have %esqlOC_RUNTIME% is in %PATH% when running the program already?
Is there any change in runtime behaviour with the runtime checks and debugging code you now have activated?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As it gave some confusion, in relation to this example, in the question (32 bits or 64 bits). My notbook is 64 bits, for windows 10 and Linux Ubuntu 16.04. I ask: What is the correct link to download the GNUcobol version (64 bits) for Linux Ubuntu and also what is the correct link to download the GNUcobol version (64 bits) for windows 10.
Celso Henrique.
P.S.:
With the help of Simon Sobisch, I managed to compile this example program, I will study some more, because the executable, did not execute correctly, it gave error. I'll try to find out where, maybe it could be an error in connecting to the MYSQL database.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@jklowden: I've edited your post to fix the link to the current gitea repo and included a link to the esqlOC place under contrib. I want to encourage you to do the later also in your repo's README and possibly switch your local contrib symlink to a getEsql.sh that places it in that folder + have it git.ignore'd.
Thanks, Simon. So far, my user count is 0 with a possibility of 1. As the work continues, if there's interest, I'll look for a better way to package it. Probably best is just to require esql be installed, and remove the symlink altogether.
Dears friends.
Thank you James K. Lowden, I will redo this example here, again, then I will pass on the result to you. I hope I don't have to configure anything, as I'm not good at doing that.
Celso Henrique
Dears friends.
I went to run this program on windows 10, but gave the following error:
Where am I going wrong?
Celso Henrique
adding
-L"%esqlOC_RUNTIME%" -ocsql
may help, otherwise try adding%esqlOC_RUNTIME%\ocsql.lib
directly.Dear Simon.
I didn't understand what it is to do.
Celso Henrique.
You're using a GCC based version, therefore you can drop the vcvarsall call. As
-fixed
is the default you also don't need to specify it on the command line. But in any case it is necessary to tell cobc to link against the library and where to found it. So this gives two possible command lines... and a possible third I did not thought about before:... but this looks like a mixture of GCC and VS-based libraries which may/may not work that way.
Dear Simon
I tested it with the three forms above, but only the second one compiled it, but it still gives an error :
Celso Henrique.
The second one was a typo by me, should have been
-locsql
, for the third place a space after the-Q
- and in all three cases: esnure thatesqlOC_RUNTIME
is set as you've previously did.Dear Simon
Correcting for the correct form, gave the following:
Celso Henrique.
Where am I going wrong?
I guess both ways will work if you use a matching architecture -
cobc --info
likely reports itself as 32bit, doesn't it? In this case use the x86 directory of esqloc (or a 64bit version of cobc if you want to stick to x64).Dear Simon.
cobc is:
what am I doing wrong?
Celso Henrique.
P.S.:
GNUcobol in a LINUX environment, I can already develop more; but GNUcobol in windows 10 environment, I am completely lost.
esqlOC_RUNTIME
should point to the x86 directory, not the x64 one as it must match the version of cobc (and yours says "64bit-mode: no")Dears.
One thing I find strange, is that, every time I go to DOS, I have to type the following command: " call "C: \ OpenCobolIDE \ GnuCOBOL \ set_env.cmd " ". what I have to do, so that I don’t have to type this command every time.
Celso Henrique.
Take a decision: either use a minimal wrapper (safe but a bit overhead) that is placed in
PATH
or set it up similar to the GNU/Linux environment.For the first option:
setx PATH=%PATH%;C:\OpenCobolIDE\GnuCOBOL\bin
For the second option:
C:\OpenCobolIDE\GnuCOBOL\bin\set_env.cmd
onceset COB
to see all GnuCOBOL related variablessetx COB...=%COB...%
setx PATH=C:\OpenCobolIDE\GnuCOBOL\bin;%PATH%
setx PATH=%PATH%;C:\OpenCobolIDE\GnuCOBOL\bin
Dear Simon.
My system are windows 10 ---> 64bits
my GNUcobol ---> 64 bits
too
Celso Henrique
Hm, no? Actually I've explicit added the 64bit-mode output to
cobc --info
to ease debugging of issues like that.You're very likely (99%) running Win10 64bit with GnuCOBOL 32bit, which is not necessarily a bad setup btw. But you can only link against 32bit libs/dlls in this case (as I've said: no problem as the system has defined borders, mainly
CALL 'SYSTEM'
[another executable] and all IPC like socket, named-pipes, message queue, ... and ODBC [so your DB server may be 64bit]).Just retry with the x86 setup for esqlOC and you're likely get further.
Dear Simon.
This time it worked, I used it as if it were 32 bits.
But when it came to running the "exe" program, it didn't, it gave an error.
Celso Henrique.
Good to see that the linking works as expected now. Things to do next: add
-debug -g
to the command line and see if you get any different output with one of those commands.And ensure that
%esqlOC_RUNTIME%
is in%PATH%
when running this program.Dear Simon
It gave the following result with these two compilation directives:
Celso Henrique
So far expected, and the running module?
Dear Simon.
In the directory that I ran this example program, five more files appeared, I will send it to you as attached files.
These are the result of
-g
and needed for debugging in "C" (I think we can jsut ignore those). Do you have%esqlOC_RUNTIME%
is in%PATH%
when running the program already?Is there any change in runtime behaviour with the runtime checks and debugging code you now have activated?
Dear Simon
Do you have %esqlOC_RUNTIME% is in %PATH% when running the program already?
Yes.
Celso Henrique
Dears.
As it gave some confusion, in relation to this example, in the question (32 bits or 64 bits). My notbook is 64 bits, for windows 10 and Linux Ubuntu 16.04. I ask: What is the correct link to download the GNUcobol version (64 bits) for Linux Ubuntu and also what is the correct link to download the GNUcobol version (64 bits) for windows 10.
Celso Henrique.
P.S.:
With the help of Simon Sobisch, I managed to compile this example program, I will study some more, because the executable, did not execute correctly, it gave error. I'll try to find out where, maybe it could be an error in connecting to the MYSQL database.