Date: Thu, 14 Sep 2000 09:33:50 -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: <200009141633.JAA02393@vashon.polstra.com> In-Reply-To: <200009141529.JAA17389@nomad.yogotech.com> References: <4F88710E19D4D311B36A00508B08FD0F2C84DA@nyplme11.neuilly.ratp> <200009140049.RAA01334@vashon.polstra.com> <200009141529.JAA17389@nomad.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200009141529.JAA17389@nomad.yogotech.com>, Nate Williams <nate@yogotech.com> wrote: > 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. At that time I asked PHK what the reasons were for eliminating the shared libgcc. (He is the person who got rid of it. See "src/gnu/lib/libgcc/Makefile" revisions 1.5 - 1.8.) He said he didn't think it would be a problem to make it shared again. 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. The non-shared libgcc used to work for us mainly because on the i386 architecture practically nothing from libgcc was ever 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. 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. The egcs team used to argue vociferously against making libgcc shared. However, I found their list of reasons and decided that they didn't apply to us. In my view, many of the reasons boiled down to, "It would be too inconvenient for Red Hat." I.e., they didn't want to use their shared library version numbers the way they are supposed to be used. Also, many of the arguments against a shared libgcc which might make sense when gcc is a 3rd-party add-on just don't apply when it is _the_ system compiler. I don't follow the gcc mailing lists any more, but David O'Brien told me some months ago that they had done a complete turn-around on the issue and were planning on making libgcc shared again. (David, please correct me if I'm misrepresenting what you told me.) 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?200009141633.JAA02393>