In order to ensure that programs, once they have been re-linked with DODS client libraries, can still access local data stores (e.g., files) is is necessary to add software which can read those local data to the functions in the re-implemented library. Typically in each function in the new library the state information accessed by the identifier passed to the function is used to determine if the call is to access local or remote data. In the former case, the function must do exactly what the original implementation of the API would have done to satisfy the function call.
It is wasteful to completely recode the entire API just to achieve local access, however, it is also not possible to simply link the user program with both the DODS client library and the original library. It is not possible to link with both the DODS client library and the original library because both must define the same external symbols. Linking with both libraries will produce link-time conflicts on most computers or result in an incorrectly linked binary image.
In order to use the original implementation of the library, it is necessary to rename all of its external symbols that will appear in user programs. For example, if an API defines four functions (open, close, read and write) and one global variable (errno), then each of those must be renamed to some new symbol (e.g., orig_open, orig_close, ...). These source modules can then be added to the set of object modules used to build the DODS client library. Of course the DODS client library must also include the original external symbol names; one approach is to recode each of the APIs external symbols as a function which either calls the DODS-replacement or the original function (now renamed so that the symbols do not conflict) depending on whether the access is local or remote.