From owner-cvs-lib Mon Jan 29 12:16:40 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA28958 for cvs-lib-outgoing; Mon, 29 Jan 1996 12:16:40 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA28943 Mon, 29 Jan 1996 12:16:36 -0800 (PST) Date: Mon, 29 Jan 1996 12:16:36 -0800 (PST) From: Mike Pritchard Message-Id: <199601292016.MAA28943@freefall.freebsd.org> To: CVS-committers, cvs-lib Subject: cvs commit: src/lib/libc/net getservent.c Sender: owner-cvs-lib@FreeBSD.ORG Precedence: bulk mpp 96/01/29 12:16:34 Modified: lib/libc/gen getpwent.c lib/libc/net getservent.c Log: Getpwent() and getservent() can wind up calling free() with an invalid pointer if a call to yp_first() fails. Closes PR # 964, and possibly # 952. Revision Changes Path 1.31 +0 -1 src/lib/libc/gen/getpwent.c 1.3 +0 -1 src/lib/libc/net/getservent.c From owner-cvs-lib Mon Jan 29 21:55:37 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA28934 for cvs-lib-outgoing; Mon, 29 Jan 1996 21:55:37 -0800 (PST) Received: (from nate@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA28917 Mon, 29 Jan 1996 21:55:30 -0800 (PST) Date: Mon, 29 Jan 1996 21:55:30 -0800 (PST) From: Nate Williams Message-Id: <199601300555.VAA28917@freefall.freebsd.org> To: CVS-committers, cvs-lib Subject: cvs commit: src/lib/csu/i386 crt0.c Sender: owner-cvs-lib@FreeBSD.ORG Precedence: bulk nate 96/01/29 21:55:28 Modified: lib/csu/i386 crt0.c Log: Back out the thread_init code in order to allow -current to bootstrap from -stable, until a better solution is found. Submitted by: Consensus of mailing list and the almighty Jordan :) Revision Changes Path 1.23 +0 -8 src/lib/csu/i386/crt0.c From owner-cvs-lib Tue Jan 30 03:07:24 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA04351 for cvs-lib-outgoing; Tue, 30 Jan 1996 03:07:24 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA04301 Tue, 30 Jan 1996 03:06:59 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id LAA16210; Tue, 30 Jan 1996 11:05:07 GMT Received: from cadair.elsevier.co.uk (actually host cadair) by snowdon with SMTP (PP); Tue, 30 Jan 1996 11:05:32 +0000 Received: (from dpr@localhost) by cadair.elsevier.co.uk (8.6.12/8.6.12) id LAA16722; Tue, 30 Jan 1996 11:05:38 GMT From: Paul Richards Message-Id: <199601301105.LAA16722@cadair.elsevier.co.uk> Subject: Re: cvs commit: src/lib/csu/i386 crt0.c To: nate@freefall.freebsd.org (Nate Williams) Date: Tue, 30 Jan 1996 11:05:38 +0000 (GMT) Cc: CVS-committers@freefall.freebsd.org, cvs-lib@freefall.freebsd.org In-Reply-To: <199601300555.VAA28917@freefall.freebsd.org> from "Nate Williams" at Jan 29, 96 09:55:30 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-cvs-lib@FreeBSD.ORG Precedence: bulk In reply to Nate Williams who said > > nate 96/01/29 21:55:28 > > Modified: lib/csu/i386 crt0.c > Log: > Back out the thread_init code in order to allow -current to bootstrap > from -stable, until a better solution is found. > > Submitted by: Consensus of mailing list and the almighty Jordan :) 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. I disagree with Jordan about -current being fundamentally broken when it's actually a bootstrapping issue, these are the sorts of things you have to deal with as a -current user while people strive to find solutions. Removing stuff from -current doesn't move things forward at all. -- Paul Richards. Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-cvs-lib Tue Jan 30 08:28:24 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA03848 for cvs-lib-outgoing; Tue, 30 Jan 1996 08:28:24 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA03744 Tue, 30 Jan 1996 08:27:24 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA11970; Tue, 30 Jan 1996 09:28:14 -0700 Date: Tue, 30 Jan 1996 09:28:14 -0700 From: Nate Williams Message-Id: <199601301628.JAA11970@rocky.sri.MT.net> To: Paul Richards Cc: nate@freefall.freebsd.org (Nate Williams), CVS-committers@freefall.freebsd.org, cvs-lib@freefall.freebsd.org Subject: Re: cvs commit: src/lib/csu/i386 crt0.c In-Reply-To: <199601301105.LAA16722@cadair.elsevier.co.uk> References: <199601300555.VAA28917@freefall.freebsd.org> <199601301105.LAA16722@cadair.elsevier.co.uk> Sender: owner-cvs-lib@FreeBSD.ORG Precedence: bulk > > Back out the thread_init code in order to allow -current to bootstrap > > from -stable, until a better solution is found. > > > > Submitted by: Consensus of mailing list and the almighty Jordan :) > > 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. Julian already is trying to get a -current system running so he can solve the problem, so it only slows us down. Nate From owner-cvs-lib Tue Jan 30 08:35:18 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA04699 for cvs-lib-outgoing; Tue, 30 Jan 1996 08:35:18 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA04692 Tue, 30 Jan 1996 08:35:10 -0800 (PST) Date: Tue, 30 Jan 1996 08:35:10 -0800 (PST) From: Mike Pritchard Message-Id: <199601301635.IAA04692@freefall.freebsd.org> To: CVS-committers, cvs-lib Subject: cvs commit: src/lib/libc/sys fcntl.2 getpgrp.2 pipe.2 semctl.2 semop.2 shmat.2 shmctl.2 shmget.2 stat.2 Sender: owner-cvs-lib@FreeBSD.ORG Precedence: bulk mpp 96/01/30 08:35:07 Modified: games/bcd bcd.6 games/caesar caesar.6 sbin/i386/comcontrol comcontrol.8 sbin/i386/fdisk fdisk.8 lib/libc/gen config_open.3 directory.3 getnetgrent.3 rand48.3 lib/libc/net rcmd.3 lib/libc/nls catopen.3 lib/libc/rpc rpc.3 rstat.1 lib/libc/stdio stdio.3 lib/libc/stdlib getopt.3 malloc.3 lib/libc/string strcoll.3 strxfrm.3 lib/libc/sys fcntl.2 getpgrp.2 pipe.2 semctl.2 semop.2 shmat.2 shmctl.2 shmget.2 stat.2 Log: Fix even more spelling errors in some more man pages. Revision Changes Path 1.3 +1 -1 src/games/bcd/bcd.6 1.2 +2 -2 src/games/caesar/caesar.6 1.8 +1 -1 src/sbin/i386/comcontrol/comcontrol.8 1.6 +3 -3 src/sbin/i386/fdisk/fdisk.8 1.2 +2 -2 src/lib/libc/gen/config_open.3 1.2 +1 -1 src/lib/libc/gen/directory.3 1.2 +1 -1 src/lib/libc/gen/getnetgrent.3 1.3 +1 -1 src/lib/libc/gen/rand48.3 1.3 +1 -1 src/lib/libc/net/rcmd.3 1.2 +2 -2 src/lib/libc/nls/catopen.3 1.4 +2 -2 src/lib/libc/rpc/rpc.3 1.2 +1 -1 src/lib/libc/rpc/rstat.1 1.2 +3 -3 src/lib/libc/stdio/stdio.3 1.2 +1 -1 src/lib/libc/stdlib/getopt.3 1.4 +5 -5 src/lib/libc/stdlib/malloc.3 1.4 +1 -1 src/lib/libc/string/strcoll.3 1.4 +5 -5 src/lib/libc/string/strxfrm.3 1.3 +2 -2 src/lib/libc/sys/fcntl.2 1.2 +1 -1 src/lib/libc/sys/getpgrp.2 1.3 +1 -1 src/lib/libc/sys/pipe.2 1.2 +3 -3 src/lib/libc/sys/semctl.2 1.2 +2 -2 src/lib/libc/sys/semop.2 1.2 +3 -3 src/lib/libc/sys/shmat.2 1.2 +3 -3 src/lib/libc/sys/shmctl.2 1.2 +2 -2 src/lib/libc/sys/shmget.2 1.2 +1 -1 src/lib/libc/sys/stat.2 From owner-cvs-lib Tue Jan 30 08:47:31 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA05935 for cvs-lib-outgoing; Tue, 30 Jan 1996 08:47:31 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA05926 Tue, 30 Jan 1996 08:47:23 -0800 (PST) Date: Tue, 30 Jan 1996 08:47:23 -0800 (PST) From: Mike Pritchard Message-Id: <199601301647.IAA05926@freefall.freebsd.org> To: CVS-committers, cvs-lib Subject: cvs commit: src/lib/libc/sys getpgrp.2 semctl.2 semop.2 shmat.2 shmctl.2 shmget.2 stat.2 Sender: owner-cvs-lib@FreeBSD.ORG Precedence: bulk mpp 96/01/30 08:47:18 Branch: sbin/i386/comcontrol RELENG_2_1_0 sbin/i386/fdisk RELENG_2_1_0 lib/libc/gen RELENG_2_1_0 lib/libc/net RELENG_2_1_0 lib/libc/nls RELENG_2_1_0 lib/libc/rpc RELENG_2_1_0 lib/libc/stdio RELENG_2_1_0 lib/libc/stdlib RELENG_2_1_0 lib/libc/string RELENG_2_1_0 lib/libc/sys RELENG_2_1_0 Modified: sbin/i386/comcontrol comcontrol.8 sbin/i386/fdisk fdisk.8 lib/libc/gen config_open.3 directory.3 getnetgrent.3 rand48.3 lib/libc/net rcmd.3 lib/libc/nls catopen.3 lib/libc/rpc rpc.3 rstat.1 lib/libc/stdio stdio.3 lib/libc/stdlib getopt.3 lib/libc/string strcoll.3 strxfrm.3 lib/libc/sys getpgrp.2 semctl.2 semop.2 shmat.2 shmctl.2 shmget.2 stat.2 Log: Bring in changes from HEAD: Fix even more spelling errors in various man pages. Revision Changes Path 1.7.4.1 +1 -1 src/sbin/i386/comcontrol/comcontrol.8 1.3.4.2 +3 -3 src/sbin/i386/fdisk/fdisk.8 1.1.4.1 +2 -2 src/lib/libc/gen/config_open.3 1.1.1.1.6.1 +1 -1 src/lib/libc/gen/directory.3 1.1.1.1.6.1 +1 -1 src/lib/libc/gen/getnetgrent.3 1.2.4.1 +1 -1 src/lib/libc/gen/rand48.3 1.2.6.1 +1 -1 src/lib/libc/net/rcmd.3 1.1.4.1 +2 -2 src/lib/libc/nls/catopen.3 1.2.4.1 +2 -2 src/lib/libc/rpc/rpc.3 1.1.6.1 +1 -1 src/lib/libc/rpc/rstat.1 1.1.1.1.6.1 +3 -3 src/lib/libc/stdio/stdio.3 1.1.1.1.6.1 +1 -1 src/lib/libc/stdlib/getopt.3 1.3.4.1 +1 -1 src/lib/libc/string/strcoll.3 1.3.4.1 +5 -5 src/lib/libc/string/strxfrm.3 1.1.1.1.6.1 +1 -1 src/lib/libc/sys/getpgrp.2 1.1.2.1 +3 -3 src/lib/libc/sys/semctl.2 1.1.2.1 +2 -2 src/lib/libc/sys/semop.2 1.1.2.1 +3 -3 src/lib/libc/sys/shmat.2 1.1.2.1 +3 -3 src/lib/libc/sys/shmctl.2 1.1.2.1 +2 -2 src/lib/libc/sys/shmget.2 1.1.1.1.6.1 +1 -1 src/lib/libc/sys/stat.2 From owner-cvs-lib Tue Jan 30 10:13:22 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA13102 for cvs-lib-outgoing; Tue, 30 Jan 1996 10:13:22 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA13086 Tue, 30 Jan 1996 10:13:16 -0800 (PST) Date: Tue, 30 Jan 1996 10:13:16 -0800 (PST) From: Mike Pritchard Message-Id: <199601301813.KAA13086@freefall.freebsd.org> To: CVS-committers, cvs-lib Subject: cvs commit: src/lib/libutil setproctitle.3 Sender: owner-cvs-lib@FreeBSD.ORG Precedence: bulk mpp 96/01/30 10:13:14 Modified: lib/libcompat/SysV ftok.3 lib/libkvm kvm.3 lib/libncurses curs_attr.3 terminfo.5 lib/libscsi scsi.3 lib/libutil setproctitle.3 Log: Another round of spelling fixes. Revision Changes Path 1.2 +2 -2 src/lib/libcompat/SysV/ftok.3 1.2 +2 -2 src/lib/libkvm/kvm.3 1.3 +1 -1 src/lib/libncurses/curs_attr.3 1.2 +8 -8 src/lib/libncurses/terminfo.5 1.3 +3 -3 src/lib/libscsi/scsi.3 1.3 +2 -2 src/lib/libutil/setproctitle.3 From owner-cvs-lib Tue Jan 30 10:17:03 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA13528 for cvs-lib-outgoing; Tue, 30 Jan 1996 10:17:03 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA13517 Tue, 30 Jan 1996 10:16:59 -0800 (PST) Date: Tue, 30 Jan 1996 10:16:59 -0800 (PST) From: Mike Pritchard Message-Id: <199601301816.KAA13517@freefall.freebsd.org> To: CVS-committers, cvs-lib Subject: cvs commit: src/lib/libscsi scsi.3 Sender: owner-cvs-lib@FreeBSD.ORG Precedence: bulk mpp 96/01/30 10:16:56 Branch: lib/libcompat/SysV RELENG_2_1_0 lib/libkvm RELENG_2_1_0 lib/libncurses RELENG_2_1_0 lib/libscsi RELENG_2_1_0 Modified: lib/libcompat/SysV ftok.3 lib/libkvm kvm.3 lib/libncurses curs_attr.3 terminfo.5 lib/libscsi scsi.3 Log: Bring in another batch of spelling fixes from the main branch. Revision Changes Path 1.1.4.1 +2 -2 src/lib/libcompat/SysV/ftok.3 1.1.1.1.6.1 +2 -2 src/lib/libkvm/kvm.3 1.2.4.1 +1 -1 src/lib/libncurses/curs_attr.3 1.1.1.1.6.1 +8 -8 src/lib/libncurses/terminfo.5 1.2.4.1 +3 -3 src/lib/libscsi/scsi.3 From owner-cvs-lib Wed Jan 31 22:19:07 1996 Return-Path: owner-cvs-lib 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-cvs-lib@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 From owner-cvs-lib Thu Feb 1 01:31:38 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA10206 for cvs-lib-outgoing; Thu, 1 Feb 1996 01:31:38 -0800 (PST) Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA10171 Thu, 1 Feb 1996 01:31:04 -0800 (PST) Received: from localhost.DIALix.oz.au (peter@localhost.DIALix.oz.au [127.0.0.1]) by jhome.DIALix.COM (8.7.3/8.7.3) with SMTP id RAA13154; Thu, 1 Feb 1996 17:30:23 +0800 (WST) Message-Id: <199602010930.RAA13154@jhome.DIALix.COM> X-Authentication-Warning: jhome.DIALix.COM: Host peter@localhost.DIALix.oz.au [127.0.0.1] didn't use HELO protocol To: John Polstra 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 "Wed, 31 Jan 1996 22:18:35 PST." <199602010618.WAA13878@austin.polstra.com> Date: Thu, 01 Feb 1996 17:30:23 +0800 From: Peter Wemm Sender: owner-cvs-lib@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. 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 From owner-cvs-lib Thu Feb 1 14:19:05 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA05614 for cvs-lib-outgoing; Thu, 1 Feb 1996 14:19:05 -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 OAA05589 Thu, 1 Feb 1996 14:18:12 -0800 (PST) Received: from YAZ-PISTACHIO.MIT.EDU by MIT.EDU with SMTP id AA22490; Thu, 1 Feb 96 17:17:33 EST Received: by yaz-pistachio.MIT.EDU (5.57/4.7) id AA07409; Thu, 1 Feb 96 17:17:42 -0500 Message-Id: <9602012217.AA07409@yaz-pistachio.MIT.EDU> To: Peter Wemm Cc: John Polstra , nate@sri.MT.net, CVS-committers@freebsd.org, cvs-lib@freebsd.org, proven@MIT.EDU Subject: Re: cvs commit: src/lib/csu/i386 crt0.c In-Reply-To: Your message of "Thu, 01 Feb 1996 17:30:23 +0800." <199602010930.RAA13154@jhome.DIALix.COM> Date: Thu, 01 Feb 1996 17:17:41 EST From: Christopher Provenzano Sender: owner-cvs-lib@freebsd.org Precedence: bulk Since the bootstrapping problem is a basic mess. Might I suggest using what pthreads has done. Make a c++ constructor in the library that is called when the program is initialized. It removes the problem of having to deal with crt0.o at all. Here is how pthreads does it. init.cc extern "C" void pthread_init (void); struct __pthread_init_hack_t { __pthread_init_hack_t () { pthread_init (); } }; __pthread_init_hack_t __pthread_init_hack_x; char __pthread_init_hack = 42; In any one file that is always linked in with the library eg signal.c /* This will force init.o to get dragged in; if you've got support for C++ initialization, that'll cause pthread_init to be called at program startup automatically, so the application won't need to call it explicitly. */ extern char __pthread_init_hack; char *__pthread_init_hack_2 = &__pthread_init_hack; CAP From owner-cvs-lib Thu Feb 1 15:16:30 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA09613 for cvs-lib-outgoing; Thu, 1 Feb 1996 15:16:30 -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 PAA09594 Thu, 1 Feb 1996 15:16:18 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.6.12/8.6.12) with ESMTP id PAA29370; Thu, 1 Feb 1996 15:15:50 -0800 Message-Id: <199602012315.PAA29370@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 "Thu, 01 Feb 1996 17:30:23 +0800." <199602010930.RAA13154@jhome.DIALix.COM> Date: Thu, 01 Feb 1996 15:15:50 -0800 From: John Polstra Sender: owner-cvs-lib@freebsd.org Precedence: bulk Peter wrote: > >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 > > ... > >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 think we can fix this problem by doing a 'make depend' pass over the entire > lib source BEFORE installing anything. Er, my solution does that, too. > 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. Yes, but so will the simpler solution that I proposed, above. > > 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?? -- John From owner-cvs-lib Thu Feb 1 16:22:02 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA14016 for cvs-lib-outgoing; Thu, 1 Feb 1996 16:22:02 -0800 (PST) Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA13983 Thu, 1 Feb 1996 16:21:36 -0800 (PST) Received: from localhost.DIALix.oz.au (peter@localhost.DIALix.oz.au [127.0.0.1]) by jhome.DIALix.COM (8.7.3/8.7.3) with SMTP id IAA17373; Fri, 2 Feb 1996 08:20:48 +0800 (WST) Message-Id: <199602020020.IAA17373@jhome.DIALix.COM> X-Authentication-Warning: jhome.DIALix.COM: Host peter@localhost.DIALix.oz.au [127.0.0.1] didn't use HELO protocol To: John Polstra 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 "Thu, 01 Feb 1996 15:15:50 PST." <199602012315.PAA29370@austin.polstra.com> Date: Fri, 02 Feb 1996 08:20:47 +0800 From: Peter Wemm Sender: owner-cvs-lib@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... >-- John Cheers, -Peter From owner-cvs-lib Thu Feb 1 16:30:37 1996 Return-Path: owner-cvs-lib 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-cvs-lib@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 From owner-cvs-lib Thu Feb 1 19:09:29 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA25955 for cvs-lib-outgoing; Thu, 1 Feb 1996 19:09:29 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA25903 Thu, 1 Feb 1996 19:08:36 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA23300; Fri, 2 Feb 1996 13:57:55 +1100 Date: Fri, 2 Feb 1996 13:57:55 +1100 From: Bruce Evans Message-Id: <199602020257.NAA23300@godzilla.zeta.org.au> To: jdp@polstra.com, peter@jhome.dialix.com Subject: Re: cvs commit: src/lib/csu/i386 crt0.c Cc: CVS-committers@FreeBSD.org, cvs-lib@FreeBSD.org, nate@sri.MT.net Sender: owner-cvs-lib@FreeBSD.org Precedence: bulk >> >> 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... >Anyway, now I agree that we should use your solution in the top-level >Makefile, and not mine. I prefer John's solution together with fixing what it breaks. csu is built first to incorrectly fix `make world -DCLOBBER'. See the log for rev.1.28. The problem was that -DCLOBBER blows away the used library file crt0.o although it preserves the used library files `*.s[ao].*'. If DESTDIR isn't set, then building and installing crt0.o early results in the build utilities being linked with the _new_ crt0.o and the _old_ shared libraries (or the link failing if someone sets NOSHARED globally). Better quick fixes for this problem include: - don't remove any library files. Little would be lost, because the critical shared libraries aren't removed, so links that should fail because the appropriate new library hasn't been installed may bogusly succeed using an old shared library, and garbage shared libraries aren't removed, so -DCLOBBER's main purpose of removing junk is half defeated. - don't remove any library files if ${DESTDIR}==""; otherwise remove all library files. - remove all library files except those required to link and run the build utilities. Bruce From owner-cvs-lib Thu Feb 1 21:06:51 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA11558 for cvs-lib-outgoing; Thu, 1 Feb 1996 21:06:51 -0800 (PST) Received: (from wosch@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA11538 Thu, 1 Feb 1996 21:06:43 -0800 (PST) Date: Thu, 1 Feb 1996 21:06:43 -0800 (PST) From: Wolfram Schneider Message-Id: <199602020506.VAA11538@freefall.freebsd.org> To: CVS-committers, cvs-lib Subject: cvs commit: src/lib/libc/sys madvise.2 mincore.2 mmap.2 mprotect.2 msync.2 munmap.2 Sender: owner-cvs-lib@FreeBSD.ORG Precedence: bulk wosch 96/02/01 21:06:39 Modified: lib/libc/sys madvise.2 mincore.2 mmap.2 mprotect.2 msync.2 munmap.2 Log: Submitted by: bruce, davidg, dyson add a BUG section for mmap with current limitation section SYNOPSIS completed Revision Changes Path 1.3 +2 -0 src/lib/libc/sys/madvise.2 1.2 +2 -0 src/lib/libc/sys/mincore.2 1.2 +19 -1 src/lib/libc/sys/mmap.2 1.2 +2 -0 src/lib/libc/sys/mprotect.2 1.3 +2 -0 src/lib/libc/sys/msync.2 1.2 +2 -0 src/lib/libc/sys/munmap.2 From owner-cvs-lib Thu Feb 1 22:46:38 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA25728 for cvs-lib-outgoing; Thu, 1 Feb 1996 22:46:38 -0800 (PST) Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA25703 Thu, 1 Feb 1996 22:45:50 -0800 (PST) Received: from localhost.DIALix.oz.au (peter@localhost.DIALix.oz.au [127.0.0.1]) by jhome.DIALix.COM (8.7.3/8.7.3) with SMTP id OAA18603; Fri, 2 Feb 1996 14:44:24 +0800 (WST) Message-Id: <199602020644.OAA18603@jhome.DIALix.COM> X-Authentication-Warning: jhome.DIALix.COM: Host peter@localhost.DIALix.oz.au [127.0.0.1] didn't use HELO protocol To: Bruce Evans cc: jdp@polstra.com, 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 "Fri, 02 Feb 1996 13:57:55 +1100." <199602020257.NAA23300@godzilla.zeta.org.au> Date: Fri, 02 Feb 1996 14:44:24 +0800 From: Peter Wemm Sender: owner-cvs-lib@FreeBSD.org Precedence: bulk >>> >> 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... > >>Anyway, now I agree that we should use your solution in the top-level >>Makefile, and not mine. > >I prefer John's solution together with fixing what it breaks. > >csu is built first to incorrectly fix `make world -DCLOBBER'. See the >log for rev.1.28. The problem was that -DCLOBBER blows away the used >library file crt0.o although it preserves the used library files >`*.s[ao].*'. If DESTDIR isn't set, then building and installing crt0.o >early results in the build utilities being linked with the _new_ crt0.o >and the _old_ shared libraries (or the link failing if someone sets >NOSHARED globally). IMHO, the "safest" thing to do is ensure that we do all the compiling of the utility programs to generate library code first, before we even touch anything in /usr/lib or /usr/include. ie: (cd lib ; make depend) before doing the CLOBBER in the libraries target. Yes, we should take out the special step for csu/i386 and fix the "CLOBBER" option so that it leaves c*rt*.o alone as well. >Better quick fixes for this problem include: >- don't remove any library files. Little would be lost, because the > critical shared libraries aren't removed, so links that should fail > because the appropriate new library hasn't been installed may bogusly > succeed using an old shared library, and garbage shared libraries > aren't removed, so -DCLOBBER's main purpose of removing junk is > half defeated. >- don't remove any library files if ${DESTDIR}==""; otherwise remove > all library files. >- remove all library files except those required to link and run the > build utilities. > >Bruce -DCLOBBER doesn't seem very useful to me... We dont clean out any old junk from /usr/bin or /usr/sbin for example. -DCLOBBER should be rm -rf ${DESTDIR} - but that's probably a bit brutal. :-) :-) Cheers, -Peter From owner-cvs-lib Fri Feb 2 11:20:27 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA02170 for cvs-lib-outgoing; Fri, 2 Feb 1996 09:09:32 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA02072 Fri, 2 Feb 1996 09:09:11 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id AAA04817 ; Fri, 2 Feb 1996 00:33:44 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA04149; Fri, 2 Feb 1996 19:19:46 +1100 Date: Fri, 2 Feb 1996 19:19:46 +1100 From: Bruce Evans Message-Id: <199602020819.TAA04149@godzilla.zeta.org.au> To: bde@zeta.org.au, peter@jhome.DIALix.COM Subject: Re: cvs commit: src/lib/csu/i386 crt0.c Cc: CVS-committers@freebsd.org, cvs-lib@freebsd.org, jdp@polstra.com, nate@sri.MT.net Sender: owner-cvs-lib@freebsd.org Precedence: bulk >IMHO, the "safest" thing to do is ensure that we do all the compiling of the >utility programs to generate library code first, before we even touch >anything in /usr/lib or /usr/include. ie: (cd lib ; make depend) before >doing the CLOBBER in the libraries target. There's no guarantee that `make depend' creates all the utilities. It has to create most of them to get the dependencies right, however. If I ran `make world' a lot (I haven't tried it yet!) then I would remove the `make depend' step to speed it up a little. If NOCLEANDIR isn't defined, the .depend files are almost never used for `make world' because `make depend all' gives bogus dependencies for the `all' target (the .depend files don't exist when the dependencies are determined). Bruce From owner-cvs-lib Sat Feb 3 08:27:22 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA08856 for cvs-lib-outgoing; Sat, 3 Feb 1996 08:27:22 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA08805 Sat, 3 Feb 1996 08:26:56 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id IAA22687; Sat, 3 Feb 1996 08:26:33 -0800 From: "Rodney W. Grimes" Message-Id: <199602031626.IAA22687@GndRsh.aac.dev.com> Subject: Re: cvs commit: src/lib/csu/i386 crt0.c To: bde@zeta.org.au (Bruce Evans) Date: Sat, 3 Feb 1996 08:26:33 -0800 (PST) Cc: bde@zeta.org.au, peter@jhome.dialix.com, CVS-committers@freebsd.org, cvs-lib@freebsd.org, jdp@polstra.com, nate@sri.MT.net In-Reply-To: <199602020819.TAA04149@godzilla.zeta.org.au> from "Bruce Evans" at Feb 2, 96 07:19:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cvs-lib@freebsd.org Precedence: bulk > > >IMHO, the "safest" thing to do is ensure that we do all the compiling of the > >utility programs to generate library code first, before we even touch > >anything in /usr/lib or /usr/include. ie: (cd lib ; make depend) before > >doing the CLOBBER in the libraries target. > > There's no guarantee that `make depend' creates all the utilities. It > has to create most of them to get the dependencies right, however. > > If I ran `make world' a lot (I haven't tried it yet!) then I would > remove the `make depend' step to speed it up a little. If NOCLEANDIR > isn't defined, the .depend files are almost never used for `make world' > because `make depend all' gives bogus dependencies for the `all' target > (the .depend files don't exist when the dependencies are determined). You keep saying this, but it is not totally true, _especially_ when this command is run from a high level in the source tree. Ie, cd /usr/src; make depend all; does infact DTRT as first a full sweep over the src tree creating .depends is run, then a full pass over the tree running make all (at this point the .depends do exist). There are several cases though that should be changed to: make depend && make all. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-cvs-lib Sat Feb 3 08:49:21 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA10305 for cvs-lib-outgoing; Sat, 3 Feb 1996 08:49:21 -0800 (PST) Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA10289 Sat, 3 Feb 1996 08:49:07 -0800 (PST) Received: from localhost.DIALix.oz.au (peter@localhost.DIALix.oz.au [127.0.0.1]) by jhome.DIALix.COM (8.7.3/8.7.3) with SMTP id AAA25239; Sun, 4 Feb 1996 00:48:30 +0800 (WST) Message-Id: <199602031648.AAA25239@jhome.DIALix.COM> X-Authentication-Warning: jhome.DIALix.COM: Host peter@localhost.DIALix.oz.au [127.0.0.1] didn't use HELO protocol To: "Rodney W. Grimes" cc: bde@zeta.org.au (Bruce Evans), CVS-committers@freebsd.org, cvs-lib@freebsd.org, jdp@polstra.com, nate@sri.MT.net Subject: Re: cvs commit: src/lib/csu/i386 crt0.c In-reply-to: Your message of "Sat, 03 Feb 1996 08:26:33 PST." <199602031626.IAA22687@GndRsh.aac.dev.com> Date: Sun, 04 Feb 1996 00:48:29 +0800 From: Peter Wemm Sender: owner-cvs-lib@freebsd.org Precedence: bulk >> >> >IMHO, the "safest" thing to do is ensure that we do all the compiling of th >e >> >utility programs to generate library code first, before we even touch >> >anything in /usr/lib or /usr/include. ie: (cd lib ; make depend) before >> >doing the CLOBBER in the libraries target. >> >> There's no guarantee that `make depend' creates all the utilities. It >> has to create most of them to get the dependencies right, however. >> >> If I ran `make world' a lot (I haven't tried it yet!) then I would >> remove the `make depend' step to speed it up a little. If NOCLEANDIR >> isn't defined, the .depend files are almost never used for `make world' >> because `make depend all' gives bogus dependencies for the `all' target >> (the .depend files don't exist when the dependencies are determined). > >You keep saying this, but it is not totally true, _especially_ when >this command is run from a high level in the source tree. > >Ie, cd /usr/src; make depend all; does infact DTRT as first a full sweep >over the src tree creating .depends is run, then a full pass over the >tree running make all (at this point the .depends do exist). > >There are several cases though that should be changed to: >make depend && make all. Like the kernel compile area for example. I use 'config -n' (because I'm very aware of the dependency sideeffects when I do this and manually clean either the files themselves or do a make clean.) and have always done a "make depend ; make all". It's good to know I haven't been wasting my keystrokes.. :-) Anyway, a slight diversion.. :-) A question about the original topic. :-) It seems that linker_sets are not constructed at run-time by the dynamic linker.. (although I could be wrong) Why can't we use a c++ style constructor? all gcc supplied "main()" code contains calls to __main() in libgcc.a. ie: foo.c: main() {} becomes foo.s: .file "foo.c" gcc2_compiled.: ___gnu_compiled_c: .text .align 2 .globl _main .type _main,@function _main: pushl %ebp movl %esp,%ebp call ___main L1: leave ret Lfe1: .size _main,Lfe1-_main So, 99.999% of the problems could be solved by using the built-in gcc "glue" for linking and calling c++ code from a "c" main. It also means we can put the init code inside only libc_r and it'll all "just work" without messing with libc at all. A "c++" constructor will appear and it will call the "c" thread_init() function. This is, of course, assuming that c++ constructors in dynamic loaded shared libs is "working".... -Peter >-- >Rod Grimes rgrimes@gndrsh.aac.dev.com >Accurate Automation Company Reliable computers for FreeBSD Cheers, -Peter From owner-cvs-lib Sat Feb 3 09:27:07 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA13984 for cvs-lib-outgoing; Sat, 3 Feb 1996 09:27:07 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA13972 Sat, 3 Feb 1996 09:26:45 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id EAA22622; Sun, 4 Feb 1996 04:24:13 +1100 Date: Sun, 4 Feb 1996 04:24:13 +1100 From: Bruce Evans Message-Id: <199602031724.EAA22622@godzilla.zeta.org.au> To: bde@zeta.org.au, rgrimes@GndRsh.aac.dev.com Subject: Re: cvs commit: src/lib/csu/i386 crt0.c Cc: CVS-committers@freebsd.org, cvs-lib@freebsd.org, jdp@polstra.com, nate@sri.MT.net, peter@jhome.dialix.com Sender: owner-cvs-lib@freebsd.org Precedence: bulk >> If I ran `make world' a lot (I haven't tried it yet!) then I would >> remove the `make depend' step to speed it up a little. If NOCLEANDIR >> isn't defined, the .depend files are almost never used for `make world' >> because `make depend all' gives bogus dependencies for the `all' target >> (the .depend files don't exist when the dependencies are determined). >You keep saying this, but it is not totally true, _especially_ when >this command is run from a high level in the source tree. >Ie, cd /usr/src; make depend all; does infact DTRT as first a full sweep >over the src tree creating .depends is run, then a full pass over the >tree running make all (at this point the .depends do exist). Oops. I keep forgetting that it works for SUBDIRs. >There are several cases though that should be changed to: >make depend && make all. It should be changed for all directories that have objects in them. E.g., it should be changed for building `make' as part of the build-tools target, but it doesn't need to be changed for building cc as part of the tools target. It should be changed for building cc anyway, because the top top level Makefile shouldn't know about the layout of the lower level directories. Only 1 of the 29 `${MAKE} depend all ...' commands in /usr/src/Makefile doesn't need to be changed :-). Bruce From owner-cvs-lib Sat Feb 3 10:18:44 1996 Return-Path: owner-cvs-lib 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-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. > 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 From owner-cvs-lib Sat Feb 3 21:05:47 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA26149 for cvs-lib-outgoing; Sat, 3 Feb 1996 21:05:47 -0800 (PST) Received: (from wpaul@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA26138 Sat, 3 Feb 1996 21:05:46 -0800 (PST) Date: Sat, 3 Feb 1996 21:05:46 -0800 (PST) From: Bill Paul Message-Id: <199602040505.VAA26138@freefall.freebsd.org> To: CVS-committers, cvs-lib Subject: cvs commit: src/lib/libc/yp xdryp.c Sender: owner-cvs-lib@FreeBSD.ORG Precedence: bulk wpaul 96/02/03 21:05:45 Modified: lib/libc/yp xdryp.c Log: Make sure xdr_ypresp_all_seq() always returns a sane 'status' value. (There were cases where it was leaving the status uninitialized.) Revision Changes Path 1.5 +3 -1 src/lib/libc/yp/xdryp.c