https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Robert Dubner from comment #7)
> 1) -rdynamic
Does it need all symbols from the executable or just some particular ones?
One can also arrange to export just the needed ones...
And as has been mentioned, rdynamic is specific to a couple of targets,
grep rdynamic config/*.opt config/*/*.opt
config/darwin.opt:rdynamic
config/dragonfly.opt:rdynamic
config/freebsd.opt:rdynamic
config/gnu-user.opt:rdynamic
config/netbsd-elf.opt:rdynamic
config/sol2.opt:rdynamic
config/pa/pa-hpux.opt:rdynamic
config/xtensa/elf.opt:rdynamic
Other targets fail to compile because OPT_rdynamic just doesn't exist. So it
would need to be added through macros from config/*.h or config/*/*.h. Note,
OPT_rdynamic etc. are enumerators, not macros, so one can't even test for it
with say #ifdef OPT_rdynamic. One can surely look up if the option is in the
option tables.
> 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?
Please keep -fPIC working like it is for every other FE, don't do anything
special for it for COBOL.
It is user's responsibility to deal with -fPIC/-fpic/-fPIE/-fpie/-fno-pic
depending on what one is compiling and into what it is intended to be linked
and there are various tools that can help with that (libtool, cmake, ...).
> 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?
It is supposed to work the same like for any other library installed by GCC, I
don't see anything COBOL specific on it.
If the user installs it somewhere where the libraries aren't searched, the user
needs to tweak LD_LIBRARY_PATH for programs using it, add ld.so.conf entry for
it or do the -Wl,-rpath,xxx or -Wl,--enable-new-dtags,-rpath,xxx linking
himself, etc. The driver shouldn't do this behind user's back.
