From owner-cvs-lib Tue Feb 6 10:47:58 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA29951 for cvs-lib-outgoing; Tue, 6 Feb 1996 10:47:58 -0800 (PST) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA29904 Tue, 6 Feb 1996 10:47:45 -0800 (PST) Received: from YAZ-PISTACHIO.MIT.EDU by MIT.EDU with SMTP id AA02305; Tue, 6 Feb 96 13:45:49 EST Received: by yaz-pistachio.MIT.EDU (5.57/4.7) id AA10935; Tue, 6 Feb 96 13:45:58 -0500 Message-Id: <9602061845.AA10935@yaz-pistachio.MIT.EDU> To: John Polstra Cc: Peter Wemm , "Rodney W. Grimes" , 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 In-Reply-To: Your message of "Sat, 03 Feb 1996 10:17:53 PST." <199602031817.KAA00907@austin.polstra.com> Date: Tue, 06 Feb 1996 13:45:56 EST From: Christopher Provenzano Sender: owner-cvs-lib@freebsd.org Precedence: bulk > 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