Date: Thu, 14 Sep 2000 15:51:34 -0600 (MDT) From: Nate Williams <nate@yogotech.com> To: John Polstra <jdp@polstra.com> Cc: hackers@freebsd.org, nate@yogotech.com Subject: Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1 Message-ID: <200009142151.PAA24562@nomad.yogotech.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009142151.PAA24562>