[gmx-developers] Making libgromacs a dynamic loadable object

[Erik Lindahl]

Hi,

On Sep 29, 2013, at 11:59 AM, Teemu Murtola <teemu.murtola at iki.fi> wrote:
> 
> 
> I agree that using dlsym() is tedious. However, with proper organization of the code it should be sufficient to resolve a single C factory function using dlsym(), and return a C++ object that is used to make all other calls. Of course, if using virtual functions and other "fancy" C++ stuff is out of the question for whatever reasons, we can also implement a similar mechanism in plain C by returning a struct of function pointers. But that is _exactly_ the same thing that the C++ compiler can do for us, in a much more convenient manner, so I don't really see a point in doing that.

No, I'm definitely fine with this. In particular, by definition we will not be able to have any fancy optimization flags when compiling the source code for the general programs calling the library, so the code in those source will never be performance-sensitive.

> The interface needs to still be though out to keep it reasonable (essentially, every call across the boundary is a call through a function pointer, whether in C++ or C, so it can't be done in an inner loop), and this is where the real effort lays.
> 
> Also, we can't move everything into the binary or architecture-specific optimized libraries if we still want to make it possible for people to write tools that link against Gromacs. All code that such user tools need needs to be in an easily usable library; this includes a lot of the basic command-line processing machinery etc.

Right - I too started thinking about this when I wrote my mail. 

I suspect that by definition it is going to be too complicated to ask people to use dlsym() for all code they want to use, and then we have pretty much decided that we will need two separate libraries. 

However, even then I would prefer that the user does not have to interact with two different libraries, but that they only link to libgromacs.so, which in turn will bring in the right flavor of libgromacs_core.so.

Or can we come up with any cleaner way to do it?

Cheers,

Erik