This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch,fortran] PR 27740 Symbol versioning for libgfortran

Le Mon, Nov 06, 2006 at 10:53:10PM +0200, Janne Blomqvist écrivait/wrote:
> FX Coudert wrote:
> >
> >One question about your 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. 

I'm sorry to be picky, but I think this is no more the case, at least on not 
too old Linux systems.

On my Debian/Sid (glibc 2.3.6 compiled by gcc 4.1.2 on 2.6.18 kernel on
AMD64) man dlopen says:

   The obsolete symbols _init and _fini
       The linker recognizes special symbols _init and _fini.   If  a  dynamic
       library exports a routine named _init, then that code is executed after
       the loading, before dlopen() returns. If the dynamic library exports  a
       routine  named  _fini,  then  that  routine  is  called just before the
       library is unloaded.  In case you  need to  avoid  linking against  the
       system  startup  files,  this  can be done by giving gcc the "-nostart-
       files" parameter on the command line.

       Using these routines, or the gcc -nostartfiles or -nostdlib options, is
       not  recommended. Their use may result in undesired behavior, since the
       constructor/destructor routines will not be  executed  (unless  special
       measures are taken).

AFAIK the constructor functions (those with __attribute__((constructor)))
are executed in an unspecified orrder, which probably is the order in which
they appear.

Hope this will help, and sorry if I misunderstood you.
email: basile<at>starynkevitch<dot>net 
mobile: +33 6 8601 2359 
8, rue de la Faïencerie, 92340 Bourg La Reine, France

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]