From owner-freebsd-commit Wed Jan 31 22:19:16 1996 Return-Path: owner-commit Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA27337 for freebsd-commit-outgoing; Wed, 31 Jan 1996 22:19:16 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA27329 for cvs-all-outgoing; Wed, 31 Jan 1996 22:19:13 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA27321 for cvs-lib-outgoing; Wed, 31 Jan 1996 22:19:07 -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 WAA27303 Wed, 31 Jan 1996 22:18:49 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.6.12/8.6.12) with ESMTP id WAA13878; Wed, 31 Jan 1996 22:18:36 -0800 Message-Id: <199602010618.WAA13878@austin.polstra.com> To: nate@sri.MT.net Cc: CVS-committers@freebsd.org, cvs-lib@freebsd.org Subject: Re: cvs commit: src/lib/csu/i386 crt0.c In-Reply-To: <199601301628.JAA11970@rocky.sri.MT.net> Date: Wed, 31 Jan 1996 22:18:35 -0800 From: John Polstra Sender: owner-commit@freebsd.org Precedence: bulk Nate wrote: > > > Back out the thread_init code in order to allow -current to bootstrap > > > from -stable, until a better solution is found. > > > > Umm, I think this is a bit drastic! Bootstrapping is a problem we have to > > deal with now and again in -current and it shouldn't be a barrier to new > > development. > > Agreed, but as has been hashed out, there is no way of bootstrapping > right now inside the Makefiles. You can't do it automatically due to > races, so until a Real (tm) solution is found where folks can > automatically bootstrap, this is the temporary solution. I was studying my logs from a recent make world, and also the top-level Makefile. I was looking for something else, but in the process I came to understand the cause of the thread_init-crt0-libc bootstrapping problem. I think it could be solved in the top-level Makefile without too much trouble. The problem is in this section of code under the "libraries:" target (note: crt0 is in lib/csu/i386): .if exists(lib) cd ${.CURDIR}/lib/csu/i386 && \ ${MAKE} depend all install ${CLEANDIR} ${OBJDIR} cd ${.CURDIR}/lib && \ ${MAKE} depend all install ${CLEANDIR} ${OBJDIR} .endif The first command does this: depend in lib/csu/i386 build in lib/csu/i386 install from lib/csu/i386 Then, the second command does this: depend in lib/csu/i386 depend in lib/libc depend in lib/libcompat depend in lib/libcom_err ... the same for many more subdirectories of lib depend in lib/msun build in lib/csu/i386 build in lib/libc build in lib/libcompat build in lib/libcom_err ... the same for many more subdirectories of lib build in lib/msun install from lib/csu/i386 install from lib/libc install from lib/libcompat install from lib/libcom_err ... the same for many more subdirectories of lib install from lib/msun The problem is that the new crt0.o gets installed loooooong before the new libc gets installed -- but really, they need to be installed at almost the same time. Between the time that crt0.o is installed and libc is installed, much work is put into building the libraries in the other subdirectories of lib. For some of them (e.g., libmytinfo, where the bootstrapping problem first shows up), the build process involves compiling some programs and executing them. Those programs get linked with the new crt0.o (because it's already installed) but with the old libc. That's why the undefined symbol error is occurring. I think this particular problem could be solved quite simply, by just deleting the first command from the top-level Makefile: cd ${.CURDIR}/lib/csu/i386 && \ ${MAKE} depend all install ${CLEANDIR} ${OBJDIR} That would defer the installation of crt0.o until immediately before the installation of libc. I _believe_ there would be no negative side-effects from this change. Unfortunately, I can't test my proposed fix at the moment. But maybe this explanation will help Julian or somebody else who's working on it. If you all already knew about this, just ignore me. But I've seen some misleading stuff go by on the mailing list, referring to mysterious hidden dependencies from the makedepend step, and that's just wrong. The actual explanation is much simpler. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth