Date: Tue, 06 Feb 1996 13:45:56 EST From: Christopher Provenzano <proven@MIT.EDU> To: John Polstra <jdp@polstra.com> Cc: Peter Wemm <peter@jhome.dialix.com>, "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>, bde@zeta.org.au (Bruce Evans), CVS-committers@freebsd.org, cvs-lib@freebsd.org, nate@sri.MT.net, proven@MIT.EDU Subject: Re: cvs commit: src/lib/csu/i386 crt0.c Message-ID: <9602061845.AA10935@yaz-pistachio.MIT.EDU> In-Reply-To: Your message of "Sat, 03 Feb 1996 10:17:53 PST." <199602031817.KAA00907@austin.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Peter wrote: > > > It seems that linker_sets are not constructed at run-time by the > > dynamic linker.. (although I could be wrong) > > It's not the dynamic linker's responsibility to do anything with the > linker sets. The dynamic linker's only responsibilities in that > regard are: > > 1. Upon loading a shared library, call its function named (in C) > "_init", if one exists. (For backward compatibility, the > assembly-language name ".init" is also OK.) > > 2. Upon unloading a shared library, call its function named "_fini", > if one exists. (For backward compatibility, the > assembly-language name ".fini" is also OK.) > > If anything needs to be done with linker sets, then the "_init" > and "_fini" functions have to take care of it. The functions > provided by /usr/lib/c++rt0.o do exactly that. > > > Why can't we use a c++ style constructor? > > Yes, that's the right way to do it. See Christopher Provenzano's Feb 1 > (in the US) posting to cvs-committers, cvs-lib, and cvs-all, and my reply > to it. > > > all gcc supplied "main()" code contains calls to __main() in > > libgcc.a. > > Be careful here, it's tricky. The __main() cruft is used only for > invoking the static constructors in the main program itself -- *not* for > those in any shared library. In other words, constructors in the main > executable are invoked by __main(), but those in shared libraries are > invoked by _init(), which is called automatically by the dynamic linker. > They're two separate mechanisms. > > Since the initialization that needs to be done is an integral part of > the shared libc library, __main() should not get involved at all. > Instead, /usr/lib/c++rt0.o should be linked into the shared version of > libc, by defining CPLUSPLUSLIB (sigh) in its Makefile. Don't do that > until you've really got at least one constructor in there to call, > though. Otherwise, you'll run into the recent bug that caused > mysterious failures in awk and other programs. (I know how to fix it, > but I haven't figured out how to bootstrap it into a make world.) > > For the case of the static libc.a, anything used from the library *is* > part of the main executable. So in that case, __main() will invoke the > static constructors and destructors. > OK, why are people worried about the c library. It's only the thread libraries that need to worry about the constructor. If threads aren't used then the C library links in stupid stubs which won't need a constructor and therefore c++rt0.o won't be needed. No hacking should be necessary to continue to make the build tree work currently. It should only take extra work to add support for programs that want to link -lpthread or -luthread or -lwhateverotherthreadlibraryyouwant. CAP
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9602061845.AA10935>