COMP: force dlOpen for windows application binaries (#1238)
- when windows portable executables (.exe or .dll) files are loaded, their dependent libraries not fully loaded. For OpenFOAM this means that the static constructors which are responsible for populating run-time selection tables are not triggered, and most of the run-time selectable models will simply not be available. Possible Solution ================= Avoid this problem by defining an additional library symbol such as the following: extern "C" void libName_Load() {} in the respective library, and tag this symbol as 'unresolved' for the linker so that it will attempt to resolve it at run-time by loading the known libraries until it finds it. The link line would resemble the following: -L/some/path -llibName -ulibName_Load Pros: - Allows precise control of forced library loading Cons: - Moderately verbose adjustment of some source files (even with macro wrapping for the declaration). - Adjustment of numerous Make/options files and somewhat ad hoc in nature. - Requires additional care when implementing future libraries and/or applications. - This is the solution taken by the symscape patches (Richard Smith) Possible Solution ================= Avoid this problem by simply force loading all linked libraries. This is done by "scraping" the information out of the respective Make/options file (after pre-processing) and using that to define the library list that will be passed to Foam::dlOpen() at run-time. Pros: - One-time (very) minimal adjustment of the sources and wmake toolchain - Automatically applies to future applications Cons: - Possibly larger memory footprint of application (since all dependent libraries are loaded). - Possible impact on startup time (while loading libraries) - More sensitive to build failures. Since the options files are read and modified based on the existence of the dependent libraries as a preprocessor step, if the libraries are initially unavailable for the first attempt at building the application, the dependencies will be inaccurate for later (successful) builds. - This is solution taken by the bluecape patches (Bruno Santos) Adopted Solution ================ The approach taken by Bruno was adopted in a modified form since this appears to be the most easily maintained. Additional Notes ================ It is always possible to solve this problem by defining a corresponding 'libs (...)' entry in the case system/controlDict, which forces a dlOpen of the listed libraries. This is obviously less than ideal for large-scale changes, but can work to resolve an individual problem. The peldd utility (https://github.com/gsauthof/pe-util), which is also packaged as part of MXE could provide yet another alternative. Like ldd it can be used to determine the library dependencies of binaries or libraries. This information could be used to define an additional load layer for Windows.
Showing
- applications/utilities/parallelProcessing/redistributePar/redistributePar.C 3 additions, 1 deletion...ties/parallelProcessing/redistributePar/redistributePar.C
- applications/utilities/preProcessing/mapFields/mapFields.C 1 addition, 1 deletionapplications/utilities/preProcessing/mapFields/mapFields.C
- applications/utilities/preProcessing/mapFieldsPar/mapFieldsPar.C 1 addition, 0 deletions...tions/utilities/preProcessing/mapFieldsPar/mapFieldsPar.C
- src/OpenFOAM/include/foamDlOpenLibs.H 12 additions, 0 deletionssrc/OpenFOAM/include/foamDlOpenLibs.H
- src/OpenFOAM/include/setRootCase.H 3 additions, 0 deletionssrc/OpenFOAM/include/setRootCase.H
- wmake/makefiles/files 9 additions, 1 deletionwmake/makefiles/files
- wmake/scripts/wmakeWindowsDlOpenLibs 101 additions, 0 deletionswmake/scripts/wmakeWindowsDlOpenLibs
Please register or sign in to comment