Date: Mon, 9 Oct 2000 20:45:35 +1100 From: "Andrew Reilly" <areilly@bigpond.net.au> To: John Polstra <jdp@polstra.com> Cc: hackers@freebsd.org Subject: Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1 Message-ID: <20001009204535.A88023@gurney.reilly.home> In-Reply-To: <200009140049.RAA01334@vashon.polstra.com>; from jdp@polstra.com on Wed, Sep 13, 2000 at 05:49:11PM -0700 References: <4F88710E19D4D311B36A00508B08FD0F2C84DA@nyplme11.neuilly.ratp> <200009140049.RAA01334@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Has any more come of this? I've just started playing with LADSPA (The Linux Audio Developer's Simple Plugin API http://www.ladspa.org) on my FreeBSD 4-STABLE box, and run into a similar problem. This is an entirely C API, and the demonstration applications are all straight C, but some of the plugins themselves are written in C++. Without doing anything extra, attempting to dlopen() one of these C++ shared libraries produced an Undefined symbol __get_eh_context. In the spirit John's fix (I think): On Wed, Sep 13, 2000 at 05:49:11PM -0700, John Polstra wrote: > As a work-around, try adding this to your main program. (I am > assuming it is a C++ program too.) > > extern void terminate(void); > void (*kludge_city)(void) = terminate; I didn't actually do that (took a while to find the message in the archives), but did: (a) Changed the source file names to .cc, so that they would be compiled as C++ code, and (b) added a gratuitous class definition and use to a common file, so that __get_eh_context and friends would be included in the executable. Neither of these made the problem go away, which surprised me, because nm on the resulting executable showed the symbol to be defined. I guess the dynamic linker doesn't look in the executable, only the shared libraries? This suggestion: > Another possibility would be to link explicitly with libgcc when > creating your dynamic library: > > cc -shared -o libphptest.so ... -lgcc Works, even when the applications are compiled as ordinary C programs again. I haven't tried running a system with more than one C++ plugin yet, so I worry a little that there will be multiple definition name clashes. If the dynamic linker is smart enough to not worry about that, then this does seem to be the "right" way to go, in some sense, because the resulting shared library seems to have "pure" C linkage. Perhaps we could put something about this in the Handbook, or (better) the gcc info pages? Is there a central repository of information about FreeBSD's binutil and compiler state? I noticed a few things in the gcc info pages about ABI-affecting switches (thunks for vtables and the like). There are obviously system defaults for these switches, but I don't know where to find out what they are. -- Andrew 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?20001009204535.A88023>