From owner-freebsd-current Tue May 26 11:40:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA24559 for freebsd-current-outgoing; Tue, 26 May 1998 11:40:31 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA24535 for ; Tue, 26 May 1998 11:40:18 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA22011; Tue, 26 May 1998 12:40:17 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA07456; Tue, 26 May 1998 12:40:15 -0600 Date: Tue, 26 May 1998 12:40:15 -0600 Message-Id: <199805261840.MAA07456@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eivind Eklund Cc: Nate Williams , current@FreeBSD.ORG Subject: Re: Fix for undefined "__error" and discussion of shared object versioning In-Reply-To: <19980526201549.35268@follo.net> References: <356a9f0a.251653824@mail.cetlink.net> <199805261659.LAA19904@dyson.iquest.net> <19980526194334.44185@follo.net> <199805261750.LAA07058@mt.sri.com> <19980526201549.35268@follo.net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Eivind Eklund writes: > On Tue, May 26, 1998 at 11:50:53AM -0600, Nate Williams wrote: > > > > I really don't think that we would want to also get into compiler > > > > support issues. Tool support issues are complex enough. I can imagine > > > > that egcs (could) be stable enough for our c++ compiler, but am much > > > > less confident of it being our default c compiler. > > > > > > Personally I'd prefer to use TenDRA if at all possible. It seems to > > > be much better than GCC when you look at error control etc. > > > > Can it do shlibs? > > I don't know - is there much special it would have to do? Generating PIC code is a big prerequisite, so the assembly it generates must be capable of being relocated. I'm not 100% sure if this is a function of the compiler, but given that GCC1 couldn't do it and GCC2 could, I suspect it's a function of the compiler. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message