Date: Thu, 14 Sep 2000 10:44:41 -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: <200009141644.KAA17770@nomad.yogotech.com> In-Reply-To: <200009141633.JAA02393@vashon.polstra.com> References: <4F88710E19D4D311B36A00508B08FD0F2C84DA@nyplme11.neuilly.ratp> <200009140049.RAA01334@vashon.polstra.com> <200009141529.JAA17389@nomad.yogotech.com> <200009141633.JAA02393@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > At one point libgcc was shared (FreeBSD 1.*), and it caused way more > > problems that it solved. > > Do you remember any details? I analyzed it pretty thoroughly (I > thought) more than a year ago, and decided the shared library was the > best solution. 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. 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. We weren't making releases nearly as often then, so keeping backwards compatability was more difficult as people tended to be running -stable instead of releases. Nowadays we handle backwards compatability better, so having N different versions of libgcc is still annoying, but easier to deal with (/usr/lib/compat). > At that time, I converted my -current system to using a shared libgcc > and ran it like that for 6 months at least without any problems. I > believe David O'Brien was also using a shared libgcc for a long time > without problems. There were no problems, it was just annoying. Many were of the opinion that 'not everything should be linked shared', since it tends to clutter up /usr/lib, and also tends to slow things down. Static linking isn't always bad > The non-shared libgcc used to work for us mainly because on the i386 > architecture practically nothing from libgcc was ever used. 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..) > That is no longer the case, because of all the exception support that > has been added to it for C++. If a shared library uses exceptions (as > does libstdc++) but the main program doesn't, you get undefined symbol > errors as the original poster reported. Using a shared libgcc > completely solves that. 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? > 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? 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?200009141644.KAA17770>