From owner-freebsd-commit Thu Feb 1 16:30:52 1996 Return-Path: owner-commit Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA14810 for freebsd-commit-outgoing; Thu, 1 Feb 1996 16:30:52 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA14801 for cvs-all-outgoing; Thu, 1 Feb 1996 16:30:39 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA14793 for cvs-lib-outgoing; Thu, 1 Feb 1996 16:30:37 -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 QAA14780 Thu, 1 Feb 1996 16:30:27 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.6.12/8.6.12) with ESMTP id QAA01165; Thu, 1 Feb 1996 16:29:53 -0800 Message-Id: <199602020029.QAA01165@austin.polstra.com> To: Peter Wemm cc: nate@sri.MT.net, CVS-committers@freebsd.org, cvs-lib@freebsd.org Subject: Re: cvs commit: src/lib/csu/i386 crt0.c In-reply-to: Your message of "Fri, 02 Feb 1996 08:20:47 +0800." <199602020020.IAA17373@jhome.DIALix.COM> Date: Thu, 01 Feb 1996 16:29:53 -0800 From: John Polstra Sender: owner-commit@freebsd.org Precedence: bulk Peter wrote: > >> I think this will solve the problem... > > > >I think it will, too. But, why do you want to solve the problem by > >adding 4 lines to the Makefile, when you could solve it instead by > >removing 2 lines?? > > The only thing I was wondering about was if anything in "lib" had > c++t0.o linked into it... It doesn't look like it, but it nearly was > a while ago... Oh! Very good point! I hadn't thought of that. Probably, nothing in "lib" has c++rt0.o linked into it at the moment. But, you're right, eventually *every* shared library will have it linked in. (I figured out why that caused problems before, when I eliminated CPLUSPLUSLIB. It's easy to fix. But I haven't figured out a way to solve the associated bootstrapping problems. Sigh...) Also, if we implement Chris P's proposed solution for thread_init (using a C++ static constructor), then we will have to link c++rt0.o into libc, at least. Anyway, now I agree that we should use your solution in the top-level Makefile, and not mine. Thanks! -- John