COBOL for GCC Development

COBOLworx is developing a COBOL front end for the GCC Gnu Compiler Collection. GCOBOL is very much still under development, but it has reached a point where interested users can experiment with it.

We are also working on a version of GDB – the GNU Debugger – that has the capability of working with GCOBOL.

Installation package for the GCOBOL compiler

We have a Debian installation package for the GCOBOL compiler that is known to install properly on a Debian-11 distribution and on an Ubuntu-22.04 distribution You can download the latest experimental package for the compiler here. These are considered “Checkpoint” packages and are best most uses.

Install the downloaded file with sudo apt install ./gcobol-13_13.0.15_x86_64.deb. That installs the executable as /usr/bin/gcobol and moves the necessary libraries into place.

For those wanting to upgrade more frequently, to be closer to the current state of development, packages are built automatically for each commit. See our private registry for recent activity. These are not for the easily frustrated or faint of heart (win). They are downloaded by right-click and installed like the experimental packages.

Using COBOL for GCC

Because it is part of the GCC family, GCOBOL works very much like the gcc compiler.

Compile a COBOL program like this:

gcobol -o hello hello.cbl

and then run the resulting executable with ./hello

Installation packages for the matching GDB-COBOL debugger

We are creating a version of the GDB debugger that can trap through code generated by the GCOBOL compiler and display the contents of COBOL variables using GDB’s print command. The debugger is in the very early stages of development. Reports of missing features, unexpected behavior, and problems – it’s too soon to call them “bugs” – will be gratefully accepted.

Because Python3 is important to GDB, the executable links to the system’s libpython shared library. In order to make sure gdb-cobol executable links with the correct python library, we have separate installation packages for Ubuntu-20.04 (Python3.8), Ubuntu-22.04 (Python3.10), and Debian-11 (Python3.9)

GDB-COBOL for Ubuntu 20.04

GDB-COBOL for Ubuntu 22.04

GDB-COBOL for Debian 11

Depending on the version downloaded, install the downloaded file with one of

sudo apt install ./gdb-cobol-14_14.0.3_ubuntu20_x86_64.deb
sudo apt install ./gdb-cobol-14_14.0.6_ubuntu22_x86_64.deb
sudo apt install ./gdb-cobol-14_14.0.3_debian11_x86_64.deb

The executable file is installed as /usr/bin/gdb-cobol and is invoked with the gdb-cobol command. It is a full-functioned version of GDB based on the current “bleeding edge” development branch at We give it the name gdb-cobol to avoid interfering with the distribution /usr/bin/gdb that you very likely already have on your own system.

Things to try:

`break <line number>`
`break <program-id>`
`print <variable>`
`print/p <variable>`
`print/r <variable>`
`print <variable>=<new value>`
`print <table_name>(<subscript>)`
`print <variable>(<start>:<length>)`

Source Code

The source code for the compiler is available at That repository is public; you should be able to clone it.

As mentioned, this project is very much under development. We are trying to make sure that the master+cobol branch of the repository compiles and runs, but as it is the active development branch, there can be no guarantees. The relcan branch is intended to be more stable.

We plan to make tarballs of the source code available soon, but for now your best bet is to clone the repository.

Configuration considerations

These prerequisites should suffice to compile GCOBOL on Debian and Ubuntu systems:

sudo apt install -y git g++ make m4 flex \
libgmp-dev libmpfr-dev libmpc-dev libz-dev

You will also need bison, but it has to be version 3.8 or later. On Ubuntu 22.04 LTS, sudo apt install bison installs BISON-3.8

But on Debian-11, the same command installs BISON-3.7.5, which doesn’t do the job.

On a Debian-11 system, this worked:

mkdir -p builds
cd builds
tar -xvf bison-3.8.2.tar.xz
cd bison-3.8.2
mkdir build
cd build
../configure --prefix=/usr/local
sudo make install

That reflects certain prejudices and practices with regards to where to put things and how to build them. In particular, it’s usually safer to avoid putting things into /usr/bin on systems where a package manager expects to be in charge. Hence the prefix /usr/local

This script is known to work on Debian-11 and Ubuntu-22.04

cd ~
mkdir repos
cd repos
git clone
cd gcc-cobol
git checkout relcan
mkdir builds
cd builds
../configure \
--enable-languages=c,c++,cobol \
--prefix=/usr/local \
--with-gcc-major-version-only \
--program-suffix=-13 \
--enable-shared \
--enable-linker-build-id \
--without-included-gettext \
--enable-threads=posix \
--disable-bootstrap \
--enable-clocale=gnu \
--enable-libstdcxx-debug \
--enable-libstdcxx-time=yes \
--with-default-libstdcxx-abi=new \
--enable-gnu-unique-object \
--disable-vtable-verify \
--enable-plugin \
--enable-default-pie \
--with-system-zlib \
--with-target-system-zlib=auto \
--disable-werror \
--disable-cet \
--with-abi=m64 \
--disable-multilib \
--with-tune=generic \
--without-cuda-driver \
--enable-checking=release \
--build=x86_64-linux-gnu \
--host=x86_64-linux-gnu \
--target=x86_64-linux-gnu \
--with-build-config=bootstrap-lto-lean \
sudo make install

Because this is a manual build into /usr/local, there are shared library files that need to be moved into place so that the system can find them when the executable created with GCOBOL runs. (We haven’t yet modified the GCC make install to know about these shared libraries.)

sudo cp -d /usr/local/lib64/libgcobol* /usr/local/lib/
sudo ldconfig

At this point you’ll be able to compile a cobol file and run the resulting a.out executable:

cd ~/repos/gcc-cobol/gcc/cobol/tests/check_88
gcobol-13 check_88.cbl

What are we developing?

The GCC architecture consists of a “front end” for each language; there is a front end for C, another for FORTRAN, yet another for ADA, and so on. Each front end parses the source code and passes the decoded intent of the programmer to a “code generator” that converts each instruction to an intermediate form known as GIMPLE. The intermediate form is fed into the GCC optimizer and from there to the assembly language generator.

We are developing a COBOL front end for GCC. It takes COBOL source code as input, parses it and generates the GIMPLE tree. The COBOL front end is incorporated into GCC and becomes an executable named gcobol, which is used to compile COBOL source code files. Because gcobol is part of GCC, the output can be .o object files, .so shared objects, or executable binaries.

The Developers

The primary development team:

Marty Heyman is the team leader. He is the subject matter expert for COBOL and its uses, and is the orchestrator of our business plans.

James K. Lowden is responsible for the non-trivial effort of parsing COBOL source code. COBOL was originally created around 1958, and computer science has learned a lot about compilation in general, and context-free grammars in specific, since then. Coping with a language intentionally designed to be “…like English…” from that era is an “interesting” project.

Robert Dubner is responsible for code generation. Code generation is also an “interesting” project, mainly because so few people have occasion to generate GIMPLE that there is little documentation, and less guidance, for how to do it. Mr. Dubner suspects he is the latest in a line of front end developers forced to reverse engineer what came before in order to do it at all.