https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
Robert Dubner <rdubner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |---
Status|RESOLVED |REOPENED
CC| |rdubner at gcc dot gnu.org
--- Comment #7 from Robert Dubner <rdubner at gcc dot gnu.org> ---
The commit has the comment, "...the options had been added during development
to handle specific cases, they are no longer needed..."
That turns out not to be the case, and I am sorry I wasn't tracking it more
closely at the time.
1) -rdynamic
The patch eliminated the "-rdynamic" that I was adding to the command line
switches. COBOL provides for the instruction "CALL "xyz" ON EXCEPTION...",
where the executable code in the ON EXCEPTION clause is executed when the
program-id "xyz" can't be found. When doing static linking, a missing "xyz"
will cause a static linking error. So, GCOBOL provides the -fno-static-call
switch, which internally results in the use of dlopen/dlsym to find other
programs. The "-rdynamic" is needed so that dlsym() can find the named
function.
Also, if memory serves, the -rdynamic is needed so that the GDB-COBOL version
of GDB can behave sensibly.
So, I would like to insert that switch when compiling for the x86_64 and
aarch64 architectures. What conditional compilation variables should be used
for that?
2) -fPIC when -shared is present
In similar fashion, when I first encountered the "you should use -fPIC" when
compiling a -shared .so object, I figured, "Fine. If it's going to complain
about it being missing when the user specifies -shared, then I will insert it."
I would still like to do that for x86_64 architectures, since the switch
apparently is necessary.
I would like to go back to doing that, so, again, what should I use to figure
out at compile time that this is an x86_64 or aarch64 target?
3) At an earlier time, I was creating a preprocessor variable with
-DEXEC_LIB=$(libdir) (or something like that) that allowed gcobolspec.cc to
know where libgcobol.so was going to be installed on a straight "make install".
The discussion here indicated that was somehow a bad thing to do, and it was
removed.
The result is that after doing an ordinary default configure, make, and make
install, the gcobol compiler generates code that can't find the libgcobol.so
file, at least on my installation of Ubuntu 22. That's because the default
configure assumes --prefix=/usr/local, the library is installed in
/usr/local/lib64, and that's not in the directories specified by
/etc/ld.so.conf
I found this to be unsatisfactory, so I created the EXEC_LIB solution that was
subsequently removed.
What is supposed to happen? Is the user forced to specify
"-Wl,-rpath=/usr/local/lib64", or use LD_LIBRARY_PATH, or to change their
system configuration?
I observed, incidentally, that when I specified
--enable-languages=cobol,fortran, that gfortran produced executables that
happened to run, but only because Ubuntu apparently comes with a libgfortran.so
installed in
/usr/lib64/. With that file renamed, the "error while loading shared
libraries..." appears.
I look forward to learning what the group here thinks the solutions should to
be to these usability questions.
