https://sourceware.org/bugzilla/show_bug.cgi?id=25355
Nick Bowler <nbowler at draconx dot ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nbowler at draconx dot ca
--- Comment #2 from Nick Bowler <nbowler at draconx dot ca> ---
Summary of the issue in libtool:
libtool needs to produce C declarations for arbitrary symbols based on nm
output, in order to implement various features such as dlpreopen which depend
on putting symbol values into C data structures.
Some linkers (apparently this the case on HP-UX) are strict and won't let
function declarations refer to variables and vice versa. So the nm symbol type
is used to produce either a function or variable declaration, as appropriate.
Unfortunately, with LTO enabled the GNU linker (or does GCC do everything in
this case?) seems to also have this restriction: it is an error for a function
declaration to refer to a variable or vice versa. So libtool uses the symbol
type reported by nm to produce function declarations for functions, and
variable declarations for variables.
Unfortunately, with LTO enabled then GNU nm does not distinguish between
functions and variables (however, clang and llvm-nm seems to be fine in this
regard).
There is no obvious way to work around the LTO function/data declaration issue
in C code. It seems libtool has to know, in advance, whether any given symbol
is code or data in order to produce a declaration that will link successfully.
I see several options that would work to resolve the libtool problem:
- Fix GNU nm to report functions and variables differently (best).
- Fix GNU ld (or GCC?) so that it is not a hard error to refer to variables
with function declarations or vice versa, so the nm issue does not matter.
- Figure out another way to get the value of a symbol in C code without
knowing anything other than its name.
--
You are receiving this mail because:
You are on the CC list for the bug.
