> [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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message