>>>>> "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 versoin 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.
  
-- 
Eric Marsden


Reply via email to