I believe I found a problem in how compiled executables find libcob. $ make -B bin/test-1 /usr/local/cobol/cobc.3.x/bin/cobc -x -debug -o bin/test-1 \ -Icpy src/test-1.cob \ ../contrib/tools/CobolSQLite3/CobolSQLite3.cob -lsqlite3 Let's look at the libcob.so used by cobc and test-1: $ for F in /usr/local/cobol/cobc.3.x/bin/cobc bin/test-1 do echo $F:; ldd $F | grep libcob; done /usr/local/cobol/cobc.3.x/bin/cobc: libcob.so.4 => /usr/local/cobol/cobc.3.x/lib/libcob.so.4 (0x00007f04e9686000) bin/test-1: libcob.so.4 => /usr/local/lib/libcob.so.4 (0x00007f63ed3e2000) As you can see (sort of), cobc is linked to the runtime library for its version. But the produced executable uses another one. The runtime error is: $ bin/test-1 libcob: error: version mismatch libcob: src/test-1.cob has version 3.1-dev.0 libcob: libcob has version 3.0-rc1.0 I do not know why the runtime linker is using /usr/local/lib. There is no RPATH in test-1, and no LD_LIBRARY_PATH nor COB_* runtime variable in effect. With cobc -v, the final link step is shown: executing: gcc -Wl,--export-dynamic -o "bin/test-1" "/tmp/cob5743_0.o" "/tmp/cob5743_1.o" -L/usr/local/cobol/cobc.3.x/lib -lcob -lm -l"sqlite3" Two problems that I see: 1. IMO it's mistake to link with -L and without -Wl,-rpath. The linker is being instructed what shared library to verify against, but no information is provided to the runtime linker about that same library's location. It's an invitation for error. 2. --export-dynamic is suspect. It means symbols in the executable are accessible from the libraries. That's not the normal case; normally, the application uses the libraries, not vice-versa. As GnuCOBOL controls both the translated C code and the runtime library support, I see no reason for the executable to export anything. --jkl
