CFD Online Logo CFD Online URL
Home > Forums

Linking dynamic libraries and initializing variables

Register Blogs Members List Search Today's Posts Mark Forums Read

Rate this Entry

Linking dynamic libraries and initializing variables

Posted August 27, 2011 at 14:14 by wyldckat
Updated July 10, 2016 at 16:22 by wyldckat (added more links...)

This blog post is an effort to document the search for solutions for loading dynamically linked libraries and initializing their objects in the desired order. With me, it all started with this bug report:

Basically, OpenFOAM initializes debug values right after loading all of the necessary libraries. These debug values are read from the global controlDict files (see $WM_PROJECT_DIR/etc/controlDict in your own OpenFOAM installation, or at the git repo) during loading time, even before the main function of the calling process is executed. The code that I'm talking about is this one:
//- Define the debug information, lookup as \a Name
#define defineDebugSwitchWithName(Type, Name, DebugSwitch)                    \
    int Type::debug(::Foam::debug::debugSwitch(Name, DebugSwitch))
The debugSwitch method will load the desired variable-value pair from controlDict. So far so good... except when there is a flaw in the text code in controlDict, which triggers the error messaging system... which has been initialized yet!

This has been fixed as of OpenFOAM 2.0.x, as documented here, but this is a problem for past versions. Why you ask? Because as soon as the global controlDict is damaged, all applications would crash with a segmentation fault, due to an untimely access to an uninitialized object.

As indicated in the previous paragraph, this bug is fixed now. The solution so far has been to avoid accessing the uninitialized object, but the doubt still remains on how to force the proper order of loading and initialization. On that bug report there are already a lot of information, so I'm just going to list here the findings I've tried to make since then, in order to keep that bug report more centric on the issue itself.

So, here's the list:

Conclusions so far:
  • Hacking the loading/initialization order is probably a must. This means that for each platform+compiler, there will be different solutions, if any.
  • Using "namespace std" for the error management code seemed like a good solution, since there seems to be a careful selection on ld/gcc. But embedding it directly in libOpenFOAM doesn't seem to help things.
  • What would help the initialization order would be to separate these more basic (debug) functions to a separate and somewhat independent library. This would make it easier to enforce the initialization order, since this library would have a higher probability of being put closer to libc, pthreads and Open-MPI, therefore being initialized on time.
Views 2832 Comments 1 Edit Tags Email Blog Entry
« Prev     Main     Next »
Total Comments 1


  1. Old Comment
    I haven't confirmed this yet, but several months ago, this might have been somewhat fixed in OpenFOAM 3... namely in these commits:
    Posted June 25, 2017 at 11:34 by wyldckat wyldckat is offline

All times are GMT -4. The time now is 13:44.