Changing Object output from .o to .obj

[Rich Di Iulio]

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 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

[Simon Sobisch]

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

[Rich Di Iulio]

Simon,

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

[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 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?

Any help or insight would be great!

Rich Di Iulio

[Simon Sobisch]

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?

[Rich Di Iulio]

Simon,

I am using the same version for both environments.

Linux

cobc (GnuCOBOL) 3.1.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built     Mar 17 2021 16:18:33
Packaged  Dec 23 2020 12:04:58 UTC
C version "9.3.0"

Windows

cobc (GnuCOBOL) 3.1.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built     Dec 23 2020 20:30:50
Packaged  Dec 23 2020 12:04:58 UTC
C version (MinGW) "10.2.0"

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.

Rich Di Iulio

[Simon Sobisch]

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.