Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 01 Feb 1996 17:30:23 +0800
From:      Peter Wemm <peter@jhome.DIALix.COM>
To:        John Polstra <jdp@polstra.com>
Cc:        nate@sri.MT.net, CVS-committers@freebsd.org, cvs-lib@freebsd.org
Subject:   Re: cvs commit: src/lib/csu/i386 crt0.c 
Message-ID:  <199602010930.RAA13154@jhome.DIALix.COM>
In-Reply-To: Your message of "Wed, 31 Jan 1996 22:18:35 PST." <199602010618.WAA13878@austin.polstra.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>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.

I'm sorry I didn't pipe up and say something about this before..  I was
waiting to test my fix but have not had a chance to do a make world with a
thread_init present in crt0.c and not in the installed libc.

I think we can fix this problem by doing a 'make depend' pass over the entire
lib source BEFORE installing anything.  Doing a 'make depend' causes all
the compile programs to be generated before we mess with anything.

ie:
	cd ${.CURDIR}/lib/csu/i386 && \
		${MAKE} depend
	cd ${.CURDIR}/lib && \
		${MAKE} depend
	cd ${.CURDIR}/lib/csu/i386 && \
		${MAKE} all install ${CLEANDIR} ${OBJDIR}
	cd ${.CURDIR}/lib && \
		${MAKE} all install ${CLEANDIR} ${OBJDIR}

The "cd lib ; make depend" stage will cause the libmytinfo compilation
tools: caplist, caporder, mkbinorder and mkversion to be compiled and
linked BEFORE crt0.o is installed.

I think this will solve the problem...  (with thread_init in crt0.o and
not yet in /usr/lib/libc.*)  Because from the moment crt0.o is installed
we do not need to link any other executables until well after libc
is installed.  Compilation is not affected by those two getting out of
sync, just linking.  The 'make depend' should have taken care of that.

Index: Makefile
===================================================================
RCS file: /home/ncvs/src/Makefile,v
retrieving revision 1.74
diff -u -r1.74 Makefile
--- Makefile	1996/01/30 05:46:35	1.74
+++ Makefile	1996/02/01 09:19:48
@@ -307,10 +307,16 @@
 		${MAKE} depend all install ${CLEANDIR} ${OBJDIR}
 .endif
 .if exists(lib)
+	# make depend first, this will build code generation tools
+	# otherwise once crt0.o is installed we might get spammed
 	cd ${.CURDIR}/lib/csu/i386 && \
-		${MAKE} depend all install ${CLEANDIR} ${OBJDIR}
+		${MAKE} depend
 	cd ${.CURDIR}/lib && \
-		${MAKE} depend all install ${CLEANDIR} ${OBJDIR}
+		${MAKE} depend
+	cd ${.CURDIR}/lib/csu/i386 && \
+		${MAKE} all install ${CLEANDIR} ${OBJDIR}
+	cd ${.CURDIR}/lib && \
+		${MAKE} all install ${CLEANDIR} ${OBJDIR}
 .endif
 .if exists(usr.sbin/lex/lib)
 	cd ${.CURDIR}/usr.bin/lex/lib && \

Cheers,
-Peter



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602010930.RAA13154>