Make libbacktrace a dependency for all platforms (instead of only darwin)#2042
Conversation
climbfuji
left a comment
There was a problem hiding this comment.
That's fine with me. The library has minimal dependencies, and all of them are already in spack-stack environments as far as I can tell. As long as the CI tests pass, good from my end.
|
What does the package do? And why base_env specifically? |
|
@AlexanderRichert-NOAA it's always been in base-env, was one of the first packages ever added. @srherbener can probably provide you with the details from the IODA issue linked in the PR description if you can't access the page - it describes why the package is useful also on Linux platforms, not just macOS. I am ok moving it to jedi-base-env if that sounds better to you. |
|
I'd prefer to move it elsewhere-- Ideally I'd like to get it to where, say, |
|
@AlexanderRichert-NOAA no problem moving it to jedi-base-env. libbacktrace provides an in-memory translation of symbol addresses to their corresponding line in source code for a system stack trace dump when an exception occurs. An alternate method for this is to use addr2line, but this is a separate binary (like a system command) of which you have to fork off a child process and ingest the output. libbacktrace's in-memory nature makes it run orders of magnitude faster We want libbacktrace to be always available for our CI testing which includes checks for error conditions that throw exceptions (which include the stack traces that were running very slowly due to addr2line). |
|
Thanks for the info @srherbener! |
|
@climbfuji, @AlexanderRichert-NOAA I have moved the libbacktrace dependency from base-env to jedi-base-env. |
AlexanderRichert-NOAA
left a comment
There was a problem hiding this comment.
Thanks @srherbener
Description
This PR removes the "if darwin" qualifier on defining libbacktrace as a dependency, effectively making it a dependency for all platforms.
Dependencies
None
Issues addressed
Resolves #1965
Applications affected
This goes into the base_env package so it impacts any application using that package (which I guess is most). The driver was fixing this issue: jcsda-internal/ioda/issues/1699, and I realized that having libbacktrace might be helpful across more than JEDI applications. If not, and the consensus is to limit this to JEDI applications, I'm okay with that.
Systems affected
See above
Testing
Checklist