Which libraries you link with and which linker options you use is a local issue.
Obviously not all systems have the same feature or options.
On all Unix systems, I use the native C compiler and linker because 'gcc' is not present at all.
On Wed, May 20, 2020 at 2:14 PM James K. Lowden <jklowden@xxxxxxxxxxxxxxx> wrote:
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
Cheers
Ron Norman
