Re: RPATH problem in GnuCOBOL 3.x

[Simon Sobisch]

Am 20.05.2020 um 20:13 schrieb James K. Lowden:
> I believe I found a problem in how compiled executables find libcob.

Thank you for reporting this... although I'm not sure what to do about
it yet.

In any case it looks like the bug list or (more likely) the developer
list would be more appropriate to discuss this issue, so I ask you to
post your answer and follow ups there (ans split the symbol export part
to stay with one issue per topic).

Back to your mail...

> $ 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

The "internal" issue here is that libcob.so got some new functionality
and therefore should use 4.1 as ltversion...
If this would be the case then the runtime library from /usr/local/lib
would likely note be used at all as the link would be against
libcob.so.4.1, not libcob.so.4 ... and possibly lead to a "library not
found" error if you don't have the additional directory in LD_LIBRARY_PATH.

But as `cobcrun` obviously would use the correct one, too, we have an
additional reason to prefer this one over executables as it ensures that
the "correct" path will be used.

> 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.

Then /usr/loca/lib is part of your system search path and/or was
previously cached via ldconfig.

> 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.

I'm sure it is not a mistake to not use a not portable option in general ;-)

Yes, it is a possible invitation for an error to use -L without other
entries, but it is also the only portable way we have here, rpath is not
available anywhere and borked on some systems (we have a bunch of users
explicit disabling it because of issues).
It only has the option to get an error if you've installed multiple
versions of GnuCOBOL in different folders and have one of these
installed in a system path.

Note: something similar will happen if someone specifies -L during
configure and hasn't set up LD_LIBRARY_PATH accordingly.

I *think* (= really am not sure) that the 'libtool -install', which is
part of 'make install' adds the search path into the installed binary by
default. It would be useful to know what it actually does and if this
can simply be used during linking of the COBOL modules, too.

> 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.

At least for a COBOL module instead of a direct executable it seems
reasonable to export its entry points - libcob has to look for those
when resolving the COBOL entry points in not-yet-loaded shared objects.

I'm not sure on this point: if the "main" program has multiple entry
points and some later COBOL program does something like
        SET my-program-pointer TO ENTRY "entry-in-main"
it may not work if the symbols wouldn't be available.

> --jkl

Simon