This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch,fortran] PR 27740 Symbol versioning for libgfortran
- From: Janne Blomqvist <Janne dot Blomqvist at tkk dot fi>
- To: FX Coudert <fxcoudert at gmail dot com>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 06 Nov 2006 22:53:10 +0200
- Subject: Re: [Patch,fortran] PR 27740 Symbol versioning for libgfortran
- References: <454C89C3.2080106@tkk.fi> <C301B9DA-319F-409E-8D03-1AF84793D478@gmail.com>
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