Unload shared object (.so file) opened with dlopen() in C++

Question

The problem I'm facing is as follow:

I generate a shared object called customkinetics.so from a f90 file I use this object in a Cantera (chemistry code) written in C++ with a python interface. The object is called in a subroutine (CustomKinetics.cpp) as follow:

#include "cantera/kinetics/CustomKinetics.h"

#include <iostream>
#include <dlfcn.h>

using namespace std;

namespace Cantera 
{
  //Fortran External Routine
  extern "C"
  { 
    void customkinetics_(doublereal* P, doublereal* T, doublereal* rho, const doublereal* m_y, doublereal* wdot);
  }

  CustomKinetics::CustomKinetics(thermo_t* th) : GasKinetics(th)
  {
    printf("WARNING: Using customized kinetics from f90 file.\n");
    // Closing the library if it has already been opened
    if (handle == NULL){
        dlclose(handle);
    }
    handle = dlopen("customkinetics.so", RTLD_LAZY | RTLD_LOCAL);
    // load symbol
    ck = (ck_t) dlsym(handle, "customkinetics_");
  }

    void CustomKinetics::get_wdot_custom(doublereal* wdot)
  {

    doublereal P = thermo().pressure();
    doublereal T = thermo().temperature();
    doublereal rho = thermo().density();
    const doublereal* m_y = thermo().massFractions();

    // calculation
    ck(&P,&T,&rho,&m_y[0],&wdot[0]);
  }
}

It works fine until I overwrite the .f90 file that i then compile again thus overwriting the .so and then when I call it again I actually call the first object.

I know dlclose() is not supposed to completely remove the object from the memory but is there any way to do so ?

The fortran Makefile:

customkinetics.so: customkinetics.f90
    gfortran -c customkinetics.f90 -g -fPIC -o customkinetics.o
    gfortran -shared -o customkinetics.so customkinetics.o   

Answer 1

I think it's better to understand why the dynamic shared object is still resident rather than attempt to force it to unload. dlclose() will unload the dynamic shared object from memory if the reference count on that object drops to zero. Are you sure the number of dlopen() and dlclose() calls in your code are the same?

It's also possible the reference count was implicitly incremented due to other dependencies. Can you confirm that nothing else depends your shared object?

On a related note, you're passing NULL to the dlclose() call in your constructor. Did you intend to check if the handle is not NULL, i.e.:

// Closing the library if it has already been opened
if (handle != NULL){
    dlclose(handle);
}