[Patch,fortran] PR 27740 Symbol versioning for libgfortran

[Janne Blomqvist]

FX Coudert wrote:
> Hi Janne,
> 
> One question about your gfortran.map file: where are the _fini and _init 
> symbols coming from? From what I can see, they're only present in Linux 
> static binaries (not on shared libraries, and not on ppc-darwin static 
> ones). I'd say they're "spurious" symbols and do not need to be in the 
> map file.

_init and _fini are the shared library constructor and destructor 
functions, respectively. I.e. functions that are marked with 
__attribute__((constructor)) and __attribute__((destructor)) get 
exported as _init and _fini. When a shared library is loaded (dlopen()) 
the runtime calls _init, and when it is unloaded (dlclose() ) _fini is 
called. But you're right, at least none of glibc, libstdc++, libgomp nor 
libssp export them, so I guess they can be removed. Perhaps there is 
some special magic so that they can be called even though they are not 
exported?

> Also, something I should have thought about earlier: you only included 
> in the map file the symbols that are present on your system, but we do 
> have lots of other symbols (like functions for real16 and integer16). 
> I'm not sure there really is an automated way to grab those.

Oh. Bummer. However, some brief testing reveals that it seems possible 
to include symbols in the map files that don't exist. I.e. the map file 
could include all those r16 and i16 functions, and ld apparently doesn't 
complain if such symbols are not found.

Perhaps that's the solution to Steve's problem with csqrtf as well (if 
the problem indeed persists after bootstrapping with my version of the 
patch). If libgfortran needs to provide C99 math functions on platforms 
that don't have a C99 libc, then the current patch won't work as the 
current gfortran.map hides all the symbols not explicitly mentioned there.

On another note, you'll see that I called the first version 
GFORTRAN_1.0. Is that ok, or should we rather follow the gcc release 
version? For reference, glibc uses the glibc release, libstdc++ uses the 
gcc release versions, libgomp and libssp start from 1.0.

-- 
Janne Blomqvist