https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Robert Dubner from comment #7) > 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. Apologies, that was my understanding from the discussion here. OK this is probably going to take a little time to figure out ... taking one point at a time, > The patch eliminated the "-rdynamic" that I was adding to the command line > switches. > 1) -rdynamic a) this is a pretty big hammer (it's a blanket export everything) b) it is not available on all platforms, so there might need to be alternate arrangements made in some cases. c) ... however sometimes the big hammer is needed .. Trying to understand the underlying requirement in order to suggest possible alternates... > 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. So "xyz" is a symbol in a separate DSO? (or is it the name of the DSO?). Most platforms provide mechanisms for exporting specific symbols so that one can avoid the blanket mechanism. > When doing static linking, a missing "xyz" will cause a static linking error. On some platforms this is also the default for DSOs (and can be a policy on Linux too). But this ^ is about allowing undefined symbols at link-time.. > So, GCOBOL provides the -fno-static-call > switch, which internally results in the use of dlopen/dlsym to find other > programs. "other programs" meaning executables or symbols in other DSOs? > The "-rdynamic" is needed so that dlsym() can find the named > function. so you DSO (A) dlopen() a DSO (B), then call an exported symbol that then needs to be able to refer to symbols in the current DSO (A)? Can you not explicitly export those symbols? > Also, if memory serves, the -rdynamic is needed so that the GDB-COBOL > version of GDB can behave sensibly. It would help to know what aspect is needed. > 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? It's more a case of whether a platform supports it or not - e.g x86_64 Linux and Darwin do .. but AFAIR x86_64 Windows does not.. There might be some dance we can do with specs - but first to make sure that the requirement is understood.
