From owner-freebsd-hackers Fri Mar 21 23:16:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA13791 for hackers-outgoing; Fri, 21 Mar 1997 23:16:27 -0800 (PST) Received: from paris.CS.Berkeley.EDU (paris.CS.Berkeley.EDU [128.32.34.47]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA13786 for ; Fri, 21 Mar 1997 23:16:24 -0800 (PST) Received: from paris.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by paris.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id XAA12560; Fri, 21 Mar 1997 23:16:20 -0800 (PST) From: Josh MacDonald Message-Id: <199703220716.XAA12560@paris.CS.Berkeley.EDU> To: John Birrell cc: freebsd-hackers@freebsd.org Subject: Re: libc_r In-reply-to: Your message of "Sat, 22 Mar 1997 17:33:43 +1100." <199703220633.RAA15734@freebsd1.cimlogic.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12553.859014977.1@paris.CS.Berkeley.EDU> Date: Fri, 21 Mar 1997 23:16:19 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In current, libc_r was left as optional to avoid (a) lengthening the > build time when most people probably didn't want it; and (b) breaking > a `make world' in the event that there were problems in the libc_r > build. The binary distributions (I guess you mean SNAPs) contain what > normally gets built. Of course Jordan could read the pthread man page > too, and add WANT_LIBC_R to his environment before building a SNAP. ;-) > > I think there are enough people using libc_r now to enable it > permanently in sys/lib/Makefile, leaving an environment variable > to turn it off. There are no quirks to the libc_r build -- from > time to time edits are made to libc Makefiles without corresponding > edits in libc_r Makefiles. I'd like to merge all the Makefiles to avoid > this problem, but this adds complexity to the libc Makefiles that > people might not want. This is sort of what I suspected. Consider this (hi Jordan) a request for the above change. -josh