> >>>>> "rif" == rif <[EMAIL PROTECTED]> writes: > > rif> I need to work with a library, call it libfoo.a that consists of mixed > rif> C and C++ (the parts I need to use are all in C). I load > rif> libstdc++.so, no problem. Then I try to load libfoo.a, and I get an > rif> error that the symbol "__dso_handle" is undefined (if I don't load > rif> libstdc++.so first, I get an error that _ZNSt8ios_base4InitC1Ev is > rif> undefined). I'm not sure what to do. I don't have a good feel for > rif> what __dso_handle really is, although I know it has something to do > rif> with C vs. C++ issues and that errors of this sort often indicate some > rif> sort of version skew problem. On my (debian) system, __dso_handle is > rif> defined in each of the three files > rif> > rif> /usr/lib/gcc-lib/i486-linux/3.3.5/[crtbegin|crtbeginS|crtbeginT].o > rif> > rif> but loading any/all of these files into CMUCL doesn't seem to help. > > I doubt that there is anything specific to CMUCL in your problem; I > expect that you would run into the same problem attempting > dynamically to load this library into any other program. > > I think that this error message indicates that your libfoo.a was > incorrectly built; it should have been linked with the C runtime > libraries that you cite, but wasn't. If you are able to build the > library yourself, try generating it with gcc instead of with ld; gcc > invokes the linker with the necessary runtime libraries. > > Also note that things will in general be less painful when you > attempt to load shared libraries (.so) instead of static libraries > (.a). The mechanism that CMUCL uses to load static libraries is less > widely used than the dlopen() mechanism for shared libraries, so you > are more likely to run into problems.
I understand most of what you're saying. Certainly, programs which link *statically* to the libfoo.a work fine. You are probably correct that this problem will happen whenever one tries to load the library *dynamically* into another program --- the library was not designed for this. So I'm not sure in what sense one can say the library was "incorrectly built" --- in general, one can make a C or C++ program and link to this libfoo.a and it works. Do libraries need to be designed differently/with more care in order to be loaded dynmaically into other applications? When you say "it should have been linked with the C runtime libraries that you cite", which libraries are your referring to? I don't see why it should have to link to libstdc++.a (as it's always fine to link to that at final link time for a program), and the crtbegin stuff isn't even a library as far as I can tel. Unfortunately, the library is actually a collection of libraries built on nearly a million lines of code with a very complex build system, so I'm trying to figure out what the path of least resistance is. I'm pretty sure that the libraries ARE being linked with gcc and not ld (I can check this when I'm back at work on Monday). Any substantial modifications to the build process such as changing this if it's not the case, or changing the system to generate .so libraries, is probably not going to be possible with the resources I have. Thanks for the information and advice in any case. rif
