Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move def_en and def_v to CPP file to fix minor linking issue with singularity-eos-extra #468

Merged
merged 3 commits into from
Feb 18, 2025

Conversation

Yurlungur
Copy link
Collaborator

@Yurlungur Yurlungur commented Feb 18, 2025

PR Summary

When adding a fortran interface to singularity-eos-extra, the singularity_eos_init_utils.hpp header is needed. However, it defines def_en and def_v in global scope in a header file. This produces linking errors when using plugins. Here I resolve the linking error by simply moving the definition of these arrays into singularity_eos.cpp but still make them "available" by declaring them as extern in the original header.

@dholladay00 should I declare them constant?

PR Checklist

  • Adds a test for any bugs fixed. Adds tests for new features.
  • Format your changes by using the make format command after configuring with cmake.
  • Document any new features, update documentation for changes made.
  • Make sure the copyright notice on any files you modified is up to date.
  • After creating a pull request, note it in the CHANGELOG.md file.
  • LANL employees: make sure tests pass both on the github CI and on the Darwin CI

If preparing for a new release, in addition please check the following:

  • Update the version in cmake.
  • Move the changes in the CHANGELOG.md file under a new header for the new release, and reset the categories.
  • Ensure that any when='@main' dependencies are updated to the release version in the package.py

@Yurlungur Yurlungur added bug Something isn't working build Something to do with the build system labels Feb 18, 2025
@Yurlungur Yurlungur self-assigned this Feb 18, 2025
@dholladay00
Copy link
Collaborator

My recollection on constant was that there are runtime selectable paths in the init functions that modify the arrays thus for the sake of consistent types it's easiest to leave them as non-const.

@Yurlungur
Copy link
Collaborator Author

My recollection on constant was that there are runtime selectable paths in the init functions that modify the arrays thus for the sake of consistent types it's easiest to leave them as non-const.

Got it thanks. Can you approve if this change seems reasonable?

@Yurlungur Yurlungur merged commit b4f6475 into main Feb 18, 2025
9 checks passed
@Yurlungur Yurlungur deleted the jmm/fix-init-sg branch February 18, 2025 18:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working build Something to do with the build system
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants