- bin/tools/create-mpi-config to query/write values for system openmpi.
In some cases this can be used to avoid an mpicc requirement at runtime.
- adjust openfoam session to include -test-tutorial forwarding to the
tutorials/AutoTest. This helps with writing installation tests.
- adjust foamConfigurePaths to latest version
- removal of gperftools default config, as per develop
- align wmake have_* scripts to support version query as per current
develop branch
- use config.sh/ fallbacks when the corresponding *_ARCH_PATH is empty
(eg, BOOST, CGAL, FFTW).
This aids when building outside of the regular OpenFOAM environment.
- missed detection of system libraries when installed with multiarch
paths like /usr/lib/x86_64-linux-gnu
CONFIG: improve handling of group/user config files (#928)
- changed bashrc handling of FOAM_CONFIG_NOUSER to use
FOAM_CONFIG_MODE instead. Propagate into foamEtcFile to make this
a stickier control.
This change allows better control, but also enables cluster
installations to define their own value within the OpenFOAM prefs.sh
file to prevent users accidentally mis-configuring things if
necessary.
- remove undocumented handling of an (a)ll mode in foamEtcFile to
avoid potential pitfalls.
- add support for FOAM_CONFIG_ETC handling.
This allows injection of an extra search layer when finding
project etc files
ENH: improvements to foamConfigurePaths (#928)
- handle FOAM_CONFIG_ETC implicitly, or explicitly with the new
-etc option.
STYLE: more explicit wording in foamConfigurePaths usage (#1602)
- document that an absolute path (eg, -scotch-path) overrides/ignores
the equivalent ThirdParty setting (eg, -scotch)
- longer options -system-compiler and -third-compiler for -system
and -third, respectively. Clearer as to their purpose.
- adjust the location sanity check to look for META-INFO directory.
Set the m4 -I include accordingly to have the folllowing:
- the directory of the parser.
- include/ in the top-level source tree of the current target
(eg, src/finiteVolume/include-m4/ when compiling libfiniteVolume)
- include/ from OpenFOAM
Additional -dry-run option for makeParser, wrap-lemon for expanding m4
only.
Extend m4 wrapping support to include bison as well.
- add additional rule (ending '.ll') for the combination of
flex for C-code but compiling the result as C++.
This can be needed for re-entrant parsers.
- update bison rule to handle renaming of skeleton files.
Use a wrap-bison script to manage this.
- remove make target for wmdep (flex-based scanner), which eliminates
a bootstrap dependency on flex.
As of OpenFOAM-v1806, wmdep has been superseded by wmdepend
(ragel-based scanner).
- replace dirToString binary with shell/awk equivalent for simpler
maintenance. The utility is very rarely used (auto scanning to
create Make/files) so there is no performance difference.
- forces c++DBUG='-DFULLDEBUG -g -O0' for the compilation, to allow
localized debugging during development without file editing and
while retaining the WM_COMPILE_OPTION (eg, Opt)
Note that switching between 'wmake' and 'wmake -debug' will not
cause existing targets to be rebuilt. As before, these are driven by
the dependencies. An intermediate wclean may thus be required.
- 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.
- Eg, with surface writers now in surfMesh, there are fewer libraries
depending on conversion and sampling.
COMP: regularize linkage ordering and avoid some implicit linkage (#1238)
- provide dedicated detection 'have_ptscotch' function that can be
used after the 'have_scotch' function.
It sets the PTSCOTCH_ARCH_PATH, PTSCOTCH_INC_DIR, PTSCOTCH_LIB_DIR
and helps when the serial and parallel versions are located with
different logic.
- was for parallel compilation across multiple hosts, but less useful
with modern CPUs with higher number of cores and/or hyperthreading.
Fragile use and dependent on a 'lockfile' utility that is not often
installed.
- provide default WM_DIR if not already set, to improve robustness if a
reduced environment is used
- add etc/ to WM_PROJECT_SITE search. This makes the site directory
structure consistent with the OpenFOAM structure.
Eg,
WM_PROJECT_SITE/etc/..
WM_PROJECT_SITE/bin/..
WM_PROJECT_SITE/platforms/..
- Don't set/export WM_OSTYPE. The default is POSIX and is properly
defaulted throughout, including in CMakeLists-OpenFOAM.txt (also for
Catalyst)
- removed reliance on ParaView_INCLUDE_DIR variable for conveying the
major.minor version information when compiling. This can be somewhat
fragile and also adds variable that is an unnecessary when running
(only used when compiling).
Instead use `have_pvplugin_support` function in paraviewFunctions
wmake script to determine the maj.min from the PV_PLUGIN_PATH
since we have already defined the output path there with paraview
maj.min numbering.
Can now build with paraview from the operating system,
provided that it has develop headers available.
ParaView_VERSION=system
In the etc/config.sh/paraview setup, the maj.min is taken from
the corresponding `paraview --version` output and used when
defining the PV_PLUGIN_PATH.
During the build, the include path taken from `paraview-config`
for a system installation, from the guess installation root
of the paraview binary, or ParaView_DIR otherwise.
NB: using a system ParaView for building runTimePostProcessing is unsupported.
- these types of builds appear to have various library resolution issues
(eg, libexpat not being loaded). Additionally, the build logic does
not yet cover this type of use case.
- if FOAM_EXT_LIBBIN is unset and some scripts set this to /usr/lib*
as a fallback (eg, to avoid an undefined value) this will cause a
system library to be found before appropriate *_ARCH_PATH entry.
This was noticed during a scotch compilation without third-party:
resulting in the system library (/usr/lib64/libscotch.so) to be found
instead of the SCOTCH_ARCH_PATH location
(/usr/lib64/mpi/gcc/openmpi/lib64/).
Simply changing the search order doesn't work for use, since we wish
to retain a preference for any dynamic libraries discovered in a
real FOAM_EXT_LIBBIN.
Circumvent these issues by only taking libraries from
FOAM_EXT_LIBBIN if it also points to a location within ThirdParty.
