I have a cross-platform application. On the Windows side, I am using a Mingw environment. The object output is set to o, the same as the Linux environment. I have tried setting COB_OBJECT_EXT to obj. It does not seem to change. I even tried using the -o argument. That did not work, complains that is not a legal combination.
I have one program object code that uses the same name GUIFUNC.o. I would like to use a different object name like GUIFUNC.obj. That way, I can keep the Linux and Windows environments separate with respect of the runtime. I am currently deleting the GUIFUNC.o object when I switch environments.
On a side note. Is there is a way to stop GnuCOBOL from compiling Cobjapi objects from .o to .dll.
Three of the four objects fail when compile the original program. This only happens in Windows. This is when I create a module object.
As Always, Thank you for any help.
Rich Di iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't understand your side note. Please give a specific sample.
For the object file extension - no that is not possible as GCC want's "o" files, not "obj". If you want both object files to stay in the same place the only options are:
use a different sub-directory - this seems very reasonable in any case
use -o GUIFUNCW32 for the MinGW compile and makefiles
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, here is an example of the compiling the code. The program INIFUNC is being compiled into a .dll. This compiles okay, along with a object GUIFUNC (build as .o then into a .dll. Now the Cobjapi objects is another story. The program compiles to .dll just fine. The other programs do not compile to .dll, The following programs are; japilib, cobjapi and fileselect. I have attached a log file.
When I use my Makefile, I need to use the -i switch to enable the successful completion of my application usder Windows. Under Linux, I do not have any problems. I do not understand why it is creating the .dll in the first place. Is there a way to skip the compiling of these .dll?
I'd say you seem to use a possible bug, that may only happens on GNU/Linux or MinGW - I'd have to recheck the cobc paths.
If I understand it correctly you want to build a single dll using the COBOL source and the pre-created object files to create a "fat" binary. In this case the correct thing would be using -b switch (in both cases), from cobc --help:
-b combine all input files into a single dynamically loadable module
The question is: should an object file be seen as "input file"? In any case both environments should behave the same. [I assume that cobc --version says the same for the "Packaged" output on both environments and that those are identical versions]
Can you please share the log from the current build on GNU/Linux (after make clean) and also the logs for both environments after adding the -b option?
Last edit: Simon Sobisch 2021-07-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using the same codebase. I have attached the same log file from Windows.
As far as using the -b switch in the compiler. I am not trying to create a combined dll or so file. The compiler is creating those extensions for the Cobjapi objects. I would prefer not creating them.
I see, so the cobc path is actually identical between MinGW and GNU/Linux, that's fine.
So: I suggest to just add -b to the command line and enjoy a single compilation into a shared object.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All!,
I have a cross-platform application. On the Windows side, I am using a Mingw environment. The object output is set to
o
, the same as the Linux environment. I have tried setting COB_OBJECT_EXT toobj
. It does not seem to change. I even tried using the-o
argument. That did not work, complains that is not a legal combination.I have one program object code that uses the same name
GUIFUNC.o
. I would like to use a different object name likeGUIFUNC.obj
. That way, I can keep the Linux and Windows environments separate with respect of the runtime. I am currently deleting theGUIFUNC.o
object when I switch environments.On a side note. Is there is a way to stop GnuCOBOL from compiling
Cobjapi
objects from.o
to.dll
.Three of the four objects fail when compile the original program. This only happens in Windows. This is when I create a module object.
As Always, Thank you for any help.
Rich Di iulio
I don't understand your side note. Please give a specific sample.
For the object file extension - no that is not possible as GCC want's "o" files, not "obj". If you want both object files to stay in the same place the only options are:
-o GUIFUNCW32
for the MinGW compile and makefilesSimon,
Thank you, I used the sub-directory approach. It also make it easier to cleanup files when necessary.
As for my side note, I will come up with a example of what I am asking.
Rich Di Iulio
Okay, here is an example of the compiling the code. The program
INIFUNC
is being compiled into a.dll
. This compiles okay, along with a objectGUIFUNC
(build as.o
then into a.dll
. Now the Cobjapi objects is another story. The program compiles to.dll
just fine. The other programs do not compile to.dll
, The following programs are;japilib
,cobjapi
andfileselect
. I have attached a log file.When I use my Makefile, I need to use the
-i
switch to enable the successful completion of my application usder Windows. Under Linux, I do not have any problems. I do not understand why it is creating the.dll
in the first place. Is there a way to skip the compiling of these.dll
?Any help or insight would be great!
Rich Di Iulio
I'd say you seem to use a possible bug, that may only happens on GNU/Linux or MinGW - I'd have to recheck the cobc paths.
If I understand it correctly you want to build a single dll using the COBOL source and the pre-created object files to create a "fat" binary. In this case the correct thing would be using
-b
switch (in both cases), fromcobc --help
:The question is: should an object file be seen as "input file"? In any case both environments should behave the same. [I assume that
cobc --version
says the same for the "Packaged" output on both environments and that those are identical versions]Can you please share the log from the current build on GNU/Linux (after
make clean
) and also the logs for both environments after adding the-b
option?Last edit: Simon Sobisch 2021-07-19
Simon,
I am using the same version for both environments.
Linux
Windows
I am using the same codebase. I have attached the same log file from Windows.
As far as using the -b switch in the compiler. I am not trying to create a combined
dll
orso
file. The compiler is creating those extensions for the Cobjapi objects. I would prefer not creating them.Rich Di Iulio
I see, so the cobc path is actually identical between MinGW and GNU/Linux, that's fine.
So: I suggest to just add
-b
to the command line and enjoy a single compilation into a shared object.