From owner-freebsd-current Wed May 13 21:12:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA00229 for freebsd-current-outgoing; Wed, 13 May 1998 21:12:14 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com ([210.145.37.178]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA00208 for ; Wed, 13 May 1998 21:12:07 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id UAA06858; Wed, 13 May 1998 20:07:49 -0700 (PDT) Message-Id: <199805140307.UAA06858@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: John Birrell cc: tlambert@primenet.com (Terry Lambert), current@FreeBSD.ORG Subject: Re: Undefined symbol "___error" In-reply-to: Your message of "Thu, 14 May 1998 13:24:38 +1000." <199805140324.NAA22813@cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 May 1998 20:07:48 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Terry Lambert wrote: > > > > does this mean that ALL third party programs that use curses MUST be > > > > recompiled?!?!?! > > > > > > Recompiled, no. Relinked, yes. > > > > Actually, it's a define in a header file, si it's "recompiled". > > No, it's "relinked" so that a program will know to use the later libc. > The problem here is not that the libc major number needs to be bumped, > but *all* other libraries that use errno.h need a major number bump. > Bruce pointed this out. > > Bruce wants the change backed out. I haven't heard from anyone else. > Should I bump the major number of all the shared libraries in the > FreeBSD tree? Should I back out the change and forget about making future > objects thread-aware? Should I do nothing? Unless Bruce has a functional alternative, I think that the change needs to stay. We are going to look pretty damn stupid if we can't demonstrate a competitive threading implementation in the near future. Sabotaging the development effort in this direction for the sake of some sort of mythical "consistency" is a poor idea indeed. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message