From owner-freebsd-commit Sat Feb 3 10:18:52 1996 Return-Path: owner-commit Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA17542 for freebsd-commit-outgoing; Sat, 3 Feb 1996 10:18:52 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA17530 for cvs-all-outgoing; Sat, 3 Feb 1996 10:18:48 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA17514 for cvs-lib-outgoing; Sat, 3 Feb 1996 10:18:44 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA17488 Sat, 3 Feb 1996 10:18:24 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.6.12/8.6.12) with ESMTP id KAA00907; Sat, 3 Feb 1996 10:17:53 -0800 Message-Id: <199602031817.KAA00907@austin.polstra.com> To: Peter Wemm cc: "Rodney W. Grimes" , bde@zeta.org.au (Bruce Evans), CVS-committers@freebsd.org, cvs-lib@freebsd.org, nate@sri.MT.net Subject: Re: cvs commit: src/lib/csu/i386 crt0.c In-reply-to: Your message of "Sun, 04 Feb 1996 00:48:29 +0800." <199602031648.AAA25239@jhome.DIALix.COM> Date: Sat, 03 Feb 1996 10:17:53 -0800 From: John Polstra Sender: owner-commit@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. > This is, of course, assuming that c++ constructors in dynamic loaded > shared libs is "working".... They work perfectly fine, since well before the 2.1 release. -- John