A process will only contain one instance of the code and data of a (dynamic) foreign resource even if the foreign resource is loaded and used from more than one SICStus runtime.
This presents a problem in the likely event that the foreign resource maintains some state, e.g. global variables, between invocations of functions in the foreign resource. The global state will probably need to be separate between SICStus runtimes. Requiring a foreign resource to maintain its global state on a per SICStus runtime basis would be an incompatible change. Instead, by default, only the first SICStus runtime that loads a foreign resource will be allowed to use it. If a subsequent SICStus runtime (in the same process) tries to load the foreign resource, an error will be reported to the second SICStus runtime.
When splfr builds a foreign resource, it will also generate glue code. When the foreign resource is loaded, the glue code will set up a global variable pointing to the dispatch vector used in the foreign resource to access the SICStus API. This is similar to how an embedding application accesses the SICStus API.
The glue code will also detect if a subsequent SICStus runtime in the same process tries to initialize the foreign resource. In this case, an error will be reported.
This means that pre 3.9 foreign code should only need to be rebuilt with splfr to work with the latest version of SICStus. However, a recommended change is that all C files of a foreign resource include the header file generated by splfr. Inclusion of this generated header file may become mandatory in a future release. See The Foreign Resource Linker.