From owner-freebsd-hackers Thu Sep 14 14:51:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 7FC8737B42C for ; Thu, 14 Sep 2000 14:51:36 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA10361; Thu, 14 Sep 2000 15:51:34 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id PAA24562; Thu, 14 Sep 2000 15:51:34 -0600 (MDT) (envelope-from nate) Date: Thu, 14 Sep 2000 15:51:34 -0600 (MDT) Message-Id: <200009142151.PAA24562@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Polstra Cc: hackers@freebsd.org, nate@yogotech.com Subject: Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1 In-Reply-To: <200009142131.OAA02822@vashon.polstra.com> References: <4F88710E19D4D311B36A00508B08FD0F2C84DA@nyplme11.neuilly.ratp> <200009141529.JAA17389@nomad.yogotech.com> <200009141633.JAA02393@vashon.polstra.com> <200009141644.KAA17770@nomad.yogotech.com> <200009142131.OAA02822@vashon.polstra.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [shared libgcc?] > > If I remember right (and my memory is fuzzy for stuff that far bak) > > there were a couple of issues. > > > > 1) Speed. Shared libraries are slower than static libraries (PIC > > et. al), and the stuff in libgcc tends to be performance centric. > > True. But if we just make it link against "-lgcc" then knowledgeable > users can always add "-static" if they know how to deal with the > consequences and they need the performance. Ahh, but -static implies the entire enchilada is linked static, which may not be the case. :( > > 2) Ease of use. Everytime we upgrade or modify libgcc, it required > > keeping around the old libgcc.so. I don't think we had much > > experience with versioning back then, so we tended to either 'never' > > increment the versions or 'overdo' it. > > Luckily, libgcc doesn't seem to be changing very often/much these > days. > > > Aren't there quite a few 'math' routines inside libgcc (mods and diffs > > and all sorts of low-level 32/64 bit routines that are quite often used..) > > I think most of the stuff that's actually used for C is just for the > relatively rare 64-bit operations on the i386. Bruce would know more. I know that the JDK uses them, but then again it also does 64-bit math, so that may be the case. :) > > Ahh. Can't we just make the linker *always* add libgcc onto the end? > > Because it's a static library, if it's the symbol isn't used, then it > > won't be linked into the library? > > I assume you mean always add it onto the end when building shared > libraries. That's problematic because the exception stuff uses some > static variables inside libgcc, and you end up with multiple copies of > them. Hmmm.... > > > Also, we _desperately_ need to switch away from the setjmp/longjmp > > > exception implementation and start using the now-standard DWARF2 > > > implementation. It makes a tremendous performance difference even in > > > programs that don't use exceptions at all. (I measured it once.) But > > > that in turn requires more support from libgcc, and exacerbates the > > > problems associated with using a non-shared libgcc. > > > > How so? > > Well, I should have made that a separate topic as it doesn't have that > much to do with whether libgcc is shared or not. But what I meant > was that the DWARF2 exception support uses more stuff from libgcc, so > you're more likely to run into an undefined symbol if libgcc is not > shared. Probably a bogus point for this discussion. Gotcha... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message