I don't see ANY of the OpenCOBOL environment variables set.
You must have C:\OpenCOBOL\bin in your PATH. The C-compiler automatically called by the OpenCOBOL compiler (GNU GCC is INCLUDED in the OpenCOBOL distribution) will pass the appropriate arguments to gcc, gc1 and ld to look for include files and libraries in directories relative to that bin directory.
Sorry, I uninstalled OpenCobol since it didn't work. Attaching the vars.txt I get when I do have OpenCobol setup to the best of my ability.
I set all of the variables your PDF tutorial suggests, but when I try to cobc -x hello.cob, the compiler complains that it can't find libcob.h, which clearly indicates a missing include setting, either in the compiler (cpp I believe) cobc calls, or in some obscure environment variable that's not even documented.
Lots of folks have followed those instructions successfully, but I don't know how many of them have a "PATH" that is as "busy" as yours - it appears you may have another C compiler installed on your computer, so that might be confusing things. As an experiment, why not try a command window session that uses a bare-bones PATH, then SET the various OpenCOBOL variables manually. If that works (and I don't see why it wouldn't) then you'll need to experiment with your PATH to find the sequence that works for you.
That's a very good point! I remember trying to use this or that GNU tool and realizing that Command Prompt was instead calling a tool with the same name that's used for compiling LaTeX documents. The solution was to prepend instead of append, the desired binaries to PATH. I will adjust my installer accordingly and test it.
Nope, prepending unfortunately does not do the trick. Attaching the full trace.txt log of compiler errors.
Nope, resetting PATH to only the OpenCobol bin directory doesn't do the trick either. I get an error like "as.exe - System Error: intl-8.dll missing".
I've slowly come to realize the complexity of the Cobol compilation process. Where other programming languages either run the source code directly (interpreted) or create an executable from the source code (compiled), OpenCobol uses C as an intermediate representation and expects a secondary compiler (e.g. cl.exe, cpp.exe, gcc.exe, g++.exe) to turn that into an executable.
In a system like Mac OS X, where there's one monolithic GCC distribution, that shouldn't be a difficult requirement: just explicitly state that OpenCobol for Mac OS X requires Xcode (or if the installer and installer documentation is really hip, allow MacPorts, Fink, and Homebrew as an alternative). In systems like Ubuntu, the Linux package manager by and large has exactly one copy of GCC installed; simply requiring the "gcc" or "buildtools" package would be enough for a decent opencobol-x.y.z.deb installer.
However, in Windows, there is NO standard C compiler, and OpenCobol needs to respect that. There's Microsoft Visual Studio C++, Borland, Digital Mars, MinGW, Cygwin, ActiveState Perl, Strawberry Perl and so on. A decent OpenCobol installer for Windows should either:
- Include a modern table of acceptable C compilers and their CLI syntax, allowing OpenCobol to detect and use any of the aforementioned (MSVC++, Borland, ...) compilers that were installed on the system at the time of OpenCobol installation.
- Include its own preconfigured C compiler, which Sergey and Gary have done.
- Include a "cobc.exe" that is able to produce executables without external C compilers.
The first option is complex, because it requires cobc to have a large, up to date table of dozens of C compiler command line argument standards.
The second option is probably the cause of the compiler errors I'm getting on my machine. My purposes require MinGW and its gcc, cpp, and related binaries, which are likely interfering with OpenCobol's gcc, cpp, and related binaries. I tried to shadow MinGW's binaries by prepending the OpenCobol bin directory in my PATH, but that did not result in cobc -x hello.cob compiling successfully, and even if it did, every time I wanted to compile with MinGW, this would break my other C projects, and it would break any of my nonC projects requiring a C compiler.
I believe the third option is the most optimal, because it exposes cobc as a simple interface, exposes OpenCobol as an easy to install program for people who don't have time for
yak shaving, and doesn't infringe upon other C compilers that the programmer might be using; Programmers wishing to use OpenCobol and Perl, for example, will experience CPAN breaking, because when CPAN builds Windows-specific Perl packages, it uses Perl's included C compilers, which would be overridden in PATH with the flavor-of-the-month C compiler included with OpenCobol.
Getting cobc to create executables directly from OpenCobol source code files is not easy, but I think it should be done. Other programming languages can do it just fine, OpenCobol simply needs to get to that point of functionality.
vars.txt