[petsc-users] invalid object classid 0 between PETSc and SLEPc

[Barry Smith]

On Dec 28, 2011, at 2:48 PM, Geoffrey Irving wrote:

> On Wed, Dec 28, 2011 at 4:51 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>> On 28 December 2011 01:16, Geoffrey Irving <irving at naml.us> wrote:
>>> Hello,
>>> 
>>> I've installed PETSc 3.2 and SLEPc 3.2 on Mac OS 10.7 through MacPorts
>>> 2.0.3.  PETSc works fine by itself, but SLEPc fails on the initial
>>> EPSCreate call.  The error follows.
>>> 
>>> This is presumably a MacPorts misconfiguration issue, but thought I'd
>>> check here first to see if anyone has seen this before in a similar
>>> situation.  Only static libraries exist, so as far as I know the
>>> suggested explanation doesn't apply.  The conf directory is at
>>> http://naml.us/~irving/random/petsc-conf.tar.gz if it helps.
>>> 
>> 
>> Just in case, please run:
>> 
>> $ otool -L ./your_executable
> 
> Seems clean.
> 
> tile:petsc% otool -L ../install/flavor/lib/libother_petsc.*
> ../install/flavor/lib/libother_petsc.dylib:
> 	/Users/irving/otherlab/other/install/debug/lib/libother_petsc.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> 	/usr/local/lib/OpenMesh/libOpenMeshCore.2.0.dylib (compatibility
> version 2.0.0, current version 2.0.0)
> 	/usr/local/lib/OpenMesh/libOpenMeshTools.2.0.dylib (compatibility
> version 2.0.0, current version 2.0.0)
> 	/opt/local/lib/libmpi_cxx.1.dylib (compatibility version 2.0.0,
> current version 2.1.0)
> 	/opt/local/lib/libmpi.1.dylib (compatibility version 2.0.0, current
> version 2.2.0)
> 	/opt/local/lib/libboost_iostreams.dylib (compatibility version 0.0.0,
> current version 0.0.0)
> 	/opt/local/lib/libboost_filesystem.dylib (compatibility version
> 0.0.0, current version 0.0.0)
> 	/opt/local/lib/libboost_system.dylib (compatibility version 0.0.0,
> current version 0.0.0)
> 	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.5)
> 	/opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current
> version 1.0.6)
> 	/opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current
> version 10.0.0)
> 	/Users/irving/otherlab/other/install/debug/lib/libother_core.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> 	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
> (compatibility version 1.0.0, current version 4.0.0)
> 	/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Python
> (compatibility version 2.6.0, current version 2.6.0)
> 	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> version 52.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 159.1.0)
> ../install/flavor/lib/libother_petsc.so:
> 	/Users/irving/otherlab/other/install/debug/lib/libother_petsc.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> 	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
> (compatibility version 1.0.0, current version 4.0.0)
> 	/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Python
> (compatibility version 2.6.0, current version 2.6.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 159.1.0)
> 
> I forgot to mention that I'm linking both petsc and slepc into an
> .dylib and then into an .so which is then dynamically loaded as a
> python module.  Since both petsc and slepc are linked as static
> libraries into the .dylib but not the .so, there shouldn't be any
> issues with shared library boundaries, but I could be wrong about
> this.

    The symptom you reported is indicative in this case of having two copies of the libraries "global variables". PETSc uses global variables for profile information and to mange the registration of classes etc. It could be that the way you generate the file .so results in two sets of the variables, one gets set properly in PetscInitialize() but the other one gets used later (like in SLEPc code) and since it is not set it generates an error. I've found that on the Mac it is not difficult to accidentally this problem when building up shared libraries.

   Barry


>  The link commands are
> 
> g++ -o build/nocona/release/petsc/libother_petsc.dylib -install_name
> /Users/irving/otherlab/other/install/release/lib/libother_petsc.dylib
> -dead_strip -fvisibility=hidden -dynamiclib
> build/nocona/release/petsc/ksp.os build/nocona/release/petsc/module.os
> build/nocona/release/petsc/slepc.os build/nocona/release/petsc/util.os
> -L/opt/local/lib/petsc/lib -L/usr/local/lib/OpenMesh -L/opt/local/lib
> -Linstall/release/lib -lOpenMeshCore -lOpenMeshTools -lmpi_cxx -lmpi
> -lslepc -lboost_iostreams -lboost_filesystem -lboost_system -lz -lbz2
> -lpetsc -lX11 -lother_core -F/opt/local/Library/Frameworks -framework
> Accelerate -framework Python
> gcc -o build/nocona/release/petsc/libother_petsc.so -dead_strip
> -fvisibility=hidden -bundle -L/opt/local/lib/petsc/lib
> -L/usr/local/lib/OpenMesh -L/opt/local/lib -Linstall/release/lib
> install/release/lib/libother_petsc.dylib
> -F/opt/local/Library/Frameworks -framework Accelerate -framework
> Python
> 
>> Do you have any other PETSc/SLEPc build lying around?
> 
> I do, but they didn't show up in my environment variables.
> 
> Geoffrey