GNUcobol config issue

[Gregory A Failing]

I am trying to install GC on an Ubuntu 20.04 LTS server. Before doing the
GNUcobol install I had to install the following products:

• make/focal,now 4.2.1-1.2
• gcc/focal,now 4:9.3.0-1ubuntu2
• dh-autoreconf
• libgmp-dev (libgmp10 installed automatically)
• libncurses-dev
• texinfo
• bison (includes yacc)

There may have been one or two more but I didn't log them.

Next install is BerkeleyDB v18.1.40. All seemed to go well. The includes
and libraries are in the expected locations ie:

• 'db.h' is in /usr/local/BerkeleyDB.18.1/include
• /usr/local/BerkeleyDB.18.1/lib contains:

-rw-r--r-- 1 root root 3595610 Feb  8 15:10 libdb-18.1.a
-rw-r--r-- 1 root root     952 Feb  8 14:51 libdb-18.1.la
-rwxr-xr-x 1 root root 2261152 Feb  8 14:51 libdb-18.1.so*
lrwxrwxrwx 1 root root      13 Feb  8 15:10 libdb-18.so -> libdb-18.1.so*
-rw-r--r-- 1 root root 3595610 Feb  8 15:10 libdb.a
lrwxrwxrwx 1 root root      13 Feb  8 15:10 libdb.so -> libdb-18.1.so*

Now unpack GNUcobol ...

- cd $GNUCOBOL-BASE-FOLDER (/home/fcsisat)
- zip file gnucobol-code-r4544-trunk.zip is un-tarred, un-zipped, etc
- final folder is renamed to 'GNUcobol'
- cd GNUcobol
- build_aux/bootstrap

Next is configuration ...

export LD_LIBRARY_PATH=/usr/local/BerkeleyDB.18.1/lib:$LD_LIBRARY_PATH
./configure \
--with-curses=ncurses \
CFLAGS='-g' \
LDFLAGS=-L/usr/lib64:/usr/local/BerkeleyDB.18.1/lib \
CPPFLAGS=-I/usr/local/BerkeleyDB.18.1/include

It runs like a champ. However it fails to connect to BerkeleyDB libs.
'configure' finds 'db.h' ok but cannot locate the lib*so files. This then fails to set up support for ISAM file handling.

It also fails to install XML and JSON support but those are not a concern right now. There are a dozen or so packages for those on the system.

I include a zip file that contains:

• configure
• config.h
• config.log

Any help greatly appreciated.

Gregory

[Simon Sobisch]

At first I'd highly suggest in your case to use a nighly snapshot instead of a VCS copy from Sourceforge. To get it go to https://sourceforge.net/projects/gnucobol/files/gnu-cobol/nightly_snapshots/ and choose your best fit.
This has two benefits: It only serves you the last known working version (a VCS checkout may be known to not even build, or fail the tests on the CI server) and it provides a complete distribution-style tarball (tar file) which ships everything needed and therefore removes the need to install any of the autotools (just "make" needed, which is commonly installed or otherwise part of a "built essentials" package which will also install the C compiler), help2man, bison, flex, ... and also drops the need to run build_aux/bootstrap - just untar, possibly create a build directory, configure, make.

Without looking at config.log: I'd suggest to use LDFLAGS="-L/usr/local/BerkeleyDB.18.1/lib" (the default paths will still be searched, and if you need to specify more than one just use -L multiple times, the quotes allow for that).

config.log (which should be commonly enough to work on configuration issues) says:

configure:15694: gcc -o conftest -g -I/usr/local/BerkeleyDB.18.1/include -L/usr/lib64:/usr/local/BerkeleyDB.18.1/lib conftest.c -llibdb18.1 >&5
/usr/bin/ld: cannot find -llibdb18.1

So I guess the -L with the double colon does not work and is the issue for not finding it.

For XML/JSON you'd need the dev packages - those are the ones installed on the CI run:
libncurses-dev libdb-dev libxml2-dev libjson-c-dev unixodbc-dev (remove the second if you want a newer BDB version and install it manually up-front, remove the last when not building 4.x+ or not wanting ISAM via ODBC support).

Please come back with any questions you have about this after looking at / testing the above.

[Gregory A Failing]

Simon

Thank you for your suggestions. The following successfully builds a configuration that has ISAM support:

# GC with ISAM support only
export LD_LIBRARY_PATH=/usr/local/BerkeleyDB.18.1/lib:$LD_LIBRARY_PATH
./configure \
--with-curses=ncurses \
CFLAGS='-g' \
LDFLAGS="-L/usr/local/BerkeleyDB.18.1/lib" \
CPPFLAGS="-I/usr/local/BerkeleyDB.18.1/include"

There is no json or xml2 included because of some file location issues that I will detail in another message.

However there is still an issue with 'cobc'. It is compiled with links to 'libcob.so.4' but the libraries are named 'libcob.so.5'. ie:
~~~~
ldconfig -p | grep libcob
libcob.so.5 (libc6,x86-64) => /usr/local/lib/libcob.so.5
libcob.so (libc6,x86-64) => /usr/local/lib/libcob.so

ldd /usr/local/bin/cobc
linux-vdso.so.1 (0x00007ffdfd5c9000)
libcob.so.4 => not found
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6f012ec000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6f010fa000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6f01483000)
~~~~

As you can see links are built into '/usr/local/lib' for 'libcob.so.5'.

Did I miss a config option?

Gregory

[Simon Sobisch]

That seems indeed strange - it should be linked against libcob5 (which is GnuCOBOL 4+; in case you want to build a nightly 3.x libcob4 would be correct).
While this should not happen there is a hard workaround:
When building GnuCOBOL temporarily rename libcob4.

[Anonymous]

Simon, I apologize for not mentioning it but I took your suggestion and downloaded the latest 3.2-dev. and proceeded from there. I did a 'make clean' before deleting GC 4.? however the 'libcob.so.5' files remained. I deleted them and reran configure, make , make install. The libcob.so.4 files are now in /usr/local/lib but 'ldd /usr/local/bin/cobc' still fails to load. I had failed to run 'ldconfig'. I did that and now things seem AOK.

Incidentally xml2 was configured without '--with-xml2' being in the configuration list. Apparently the 3.2-dev config does something differently than the 4-dev ... odd.

Thanks for your suggestions.

[Simon Sobisch]

The point of configure is to check what is installed and use it as best as possible. You can override this by explicit requesting something - that should be the same for 4.x (with the exception that it changed its default from BDB to V-ISAM/VBISAM - and would configure in multiple io libraries if multiple are available [if only BDB is available it still will be used and will still be the default]).

If you are fine with the 3.2dev - lets keep this for now. Just one warning (the reason I've not published rc-1): testing showed that a CALL BY VALUE literal/constant may not work as reliable as it should (when explicit specifying WITH SIZE it works correct in both old and new versions, for other cases testing is highly suggested).