Date: Thu, 14 Sep 2000 14:31:59 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: hackers@freebsd.org Cc: nate@yogotech.com Subject: Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1 Message-ID: <200009142131.OAA02822@vashon.polstra.com> In-Reply-To: <200009141644.KAA17770@nomad.yogotech.com> References: <4F88710E19D4D311B36A00508B08FD0F2C84DA@nyplme11.neuilly.ratp> <200009141529.JAA17389@nomad.yogotech.com> <200009141633.JAA02393@vashon.polstra.com> <200009141644.KAA17770@nomad.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200009141644.KAA17770@nomad.yogotech.com>, Nate Williams <nate@yogotech.com> wrote: [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. > 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. > 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. > > 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. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa 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?200009142131.OAA02822>