Disable sigsetjmp for default compilation #196
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## dev/gfdl #196 +/- ##
============================================
- Coverage 37.13% 37.13% -0.01%
============================================
Files 262 262
Lines 72662 72666 +4
Branches 13586 13586
============================================
Hits 26985 26985
- Misses 40672 40676 +4
Partials 5005 5005
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
adcroft
approved these changes
Aug 29, 2022
The sigsetjmp function is part of the POSIX, but is not required to be defined as a symbol, and may be implemented as a macro. Since Fortran C bindings require a symbol, we cannot bind to macro implementations. The prior implementation assumed a Linux glibc binding of __sigsetjmp (accessed by a `sigsetjmp` macro), but this did not work on BSD and MacOS builds, which have a dedicated `sigsetjmp` symbol. Although the autoconf build included a macro to test and assign the symbol to `SIGSETJMP_NAME`, this did not resolve builds based on mkmf or similar build systems, and would fail to compile. To resolve this, the SIGSETJMP_NAME points to a placeholder function, `sigsetjmp_missing` which permits compilation but raises an error if called. Since this function is only used in our unit testing, and even then only for tests which would otherwise raise FATAL, this change will not disrupt any simulations. However, it does mean that only "power" users who build with either autoconf or `-DSIGSETJMP_NAME=\"...\"` will be able to run the unit tests. In practice, it should be sufficient to direct users to the autoconf builds, and no actual disruptions are expected.
Hallberg-NOAA
force-pushed
the
sigsetjmp_default
branch
from
d1f9d38 to
ba9e7f1
Compare
|
This PR has passed pipeline testing at https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/pipelines/16705. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
sigsetjmpfunction is part of the POSIX, but is not required to bedefined as a symbol, and may be implemented as a macro. Since Fortran
C bindings require a symbol, we cannot bind to macro implementations.
The prior implementation assumed a Linux glibc binding of
__sigsetjmp(accessed by a
sigsetjmpmacro), but this did not work on BSD andMacOS builds, which have a dedicated
sigsetjmpsymbol.Although the autoconf build included a macro to test and assign the
symbol to
SIGSETJMP_NAME, this did not resolve builds based on mkmf orsimilar build systems, and would fail to compile.
To resolve this, the
SIGSETJMP_NAMEpoints to a placeholder function,sigsetjmp_missingwhich permits compilation but raises an error ifcalled.
Since this function is only used in our unit testing, and even then only
for tests which would otherwise raise FATAL, this change will not
disrupt any simulations.
It does mean that only "power" users who build with either
autoconf or
-DSIGSETJMP_NAME=\"...\"will be able to run the unittests. In practice, it should be sufficient to direct users to the
autoconf builds, and no actual disruptions are expected.