Version: 1.5 When trying to
When trying to postprocess a case with my own boundary conditions that are included using
libs ( "libcompressibleFluxBCs.so" );
in system/controlDict. paraFoam fails when loading the data with this very strange fatal error:
Attempt to cast type N4Foam5token8CompoundINS_4ListIdEEEE to type N4Foam5token8CompoundINS_4ListIdEEEE
From function dynamicCast<to>(From&)
in file /home/bgschaid/OpenFOAM/OpenFOAM-1.5/src/OpenFOAM/lnInclude/typeInfo.H at line 87.
(Note that the types in the error message are identical). The case loads OK when I comment out the libs entry OR when I modify the entry to
libs ( "libOpenFOAM.so" "libcompressibleFluxBCs.so" );
but not when I modify it to
libs ( "libcompressibleFluxBCs.so" "libOpenFOAM.so");
So obviously I have to force libOpenFOAM.so to be loaded before the UDFs.
As all my systems are CentOS 5 with 64 bit I can't check whether this is a problem with the ld of that system or a general problem
Had the same problem but hadn'
Had the same problem but hadn't found out that workaround. The interesting bit is that it works for normal OF execution.
Paraview uses 'dlopen' to load the OpenFOAM reader which then does a dlopen to load those libraries. Is there something on dlopen where recursive invocation resets some flags (RTLD_LOCAL etc)? Or maybe bug?
Hi Mattijs! It gets more my
It gets more mysterious. I tried it on my Mac and there it works without the workaround. I checked: dlopen is called with the same parameters there. So I guess the problem is with the glibc-implementation of dlopen
I'm trying to run the test case of "alternateReactingFoam solver" which use the "libcompressibleFluxBCs.so", but I don't have it installed on computer.
So I get the warming:
|All times are GMT -4. The time now is 13:52.|