[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-cim] Cmpilify odd behavior
Jim - It turns out the odd behavior was simple to fix - all I needed was a reinstall of the providers and a restart of the CIMOM a few times. I must have had an old copy of the library in memory. In other news, the scripts you emailed me work with minimal tweaks using the xm-test ramdisk. I should have a patch next week to incorporate a very basic intrinsic script with the xm-test ramdisk set up. Once we know that works we can just keep building on it with future patches. Luke -----Original Message----- Szymanski, Lukasz K wrote: > > Has anyone ever seen this, when looking at Xen_Memory through YAWN? > [snip] > > [1166059840] dlSharedLibraryLoader::loadSharedLibrary dlopen returned > NULL. Error is: /usr/local/lib/cmpi/libXen_Memory.so: undefined > symbol: CMPILIFYInstance_cleanup > That symbol should be in libXen_ProviderCommon.so. Use "ldd libXen_Memory.so" to see which libXen_ProviderCommon.so it is using. Maybe you have 2 installed and libXen_Memory.so is using the pre-cmpilify one. E.g on one of my test machines klutina:/usr/local/lib64/cmpi # ldd libXen_Memory.so libXen_ProviderCommon.so.1 => /usr/local/lib64//cmpi/libXen_ProviderCommon.so.1 (0x00002b4a867c7000) libxenapi.so.1.0 => /usr/lib64/libxenapi.so.1.0 (0x00002b4a86b21000) ... You can use nm to see contents of an object, e.g. klutina:/usr/local/lib64/cmpi # nm libXen_ProviderCommon.so | grep CMPILIFYInstance_cleanup 0000000000006837 T CMPILIFYInstance_cleanup HTH, Jim _______________________________________________ Xen-cim mailing list Xen-cim@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-cim
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |