Add patches to buid_visit modules allowing successful compilation with gcc 16, - #21125
Conversation
markcmiller86
left a comment
markcmiller86
left a comment
There was a problem hiding this comment.
My comments are all basically of the same ilk...why do we need to support old libs in configurations their own developers never handled?
I ran into similar questions when moving to HDF5-2.0. On the one hand, staying on the old HDF5-1.8.x lib gave us a lot of stability (and, to be fair, The HDF Group continued to maintain 1.8 on newer compilers, OSs, etc....so we stayed on HDF5-1.8 series for like 15 years or more). But, I recognized that a lot of our other libs were being built by build_visit in configs that never even existed when those releases were made.
I think our first inclination should be to drop support for a lib in configs that it doesn't build on out of the box.
This is probably a bigger question for the team as a policy but my inclintation is that we needn't spend precious resources maintaining old libs in new configs. We just need a way to disable a lib when its requested in a config that is not supported.
That said, I'd welcome other's opinions.
| <li>build_visit now has a `--cleanup` option. When turned on it triggers deletion of src and build dirs for each library if build and install are successful.</li> | ||
| <li>MOAB was updated to version 5.6.0.</li> | ||
| <li>The `--print-files` and `--print-files-html` options were fixed so that no libraries are missing from the printed lists.</li> | ||
| <li>Issues with running build_visit on Fedora44 with gcc16 were resolved with patches to some modules.</li> |
There was a problem hiding this comment.
If you think all the work is really about gcc-16, then maybe don't mention Fedora44.
There was a problem hiding this comment.
I know you probably put a ton of work into this and so what I am about to say might feel dismissive of all that work you put in to get ADIOS1 working in this configuration.
But, ADIOS1 is no longer in active development. I think we should simiply not build it (or any other lib for that matter for the same reason) in configurations it is not supported. So, I think the right answer here is to add logic to disable it for gcc-16. On top of that, we handle ADIOS2 as an alternative.
There was a problem hiding this comment.
Asked ChatGPT about newer versions. Apparently, 1.2 is from 2006. But, it thinks there is a newer version 1.21 from 2019? Can we switch to that easily? Reason asking is same thinking cap I was wearing for ADIOS1...why should VisIt resources continue to be used to maintain old libs in new configs?
There was a problem hiding this comment.
A new version of GDAL is available, 3.13.3...just this month.
There was a problem hiding this comment.
@cyrush and @JustinPrivitera have requested a new Silo release. That will be 4.12.2. I expect to have that ready by end of this week. Should we hold off and use that?
There was a problem hiding this comment.
Regarding this patch for Silo 4.12.0, I believe this issue is already addressed on Silo's 4.12RC branch. There, we have...
#define PY_SILO_MOD_DEF(ob, name, methods) \
static struct PyModuleDef moduledef = { \
.m_base = PyModuleDef_HEAD_INIT, \
.m_name = name, \
.m_methods = methods }; \
ob = PyModule_Create(&moduledef);
Which is using partial struct initialization and named initializers instead of a longer list of comma separated stuff including many NULL because they don't apply.
I will introduce a new issue ticket for 3.6.0...to upgrade to Silo 4.12.2 and I'll remove a lot of the patches here.
|
I can get on-board with not supporting newer os/ compiler configurations for some of our extremely old I/O libraries. However, we are notoriously slow in updating to newer versions. Seems we would end up dropping quite a few for users on newer systems unless we made a concerted effort to update libraries that have newer versions available. I agree the whole team should weigh in on this. If we go down the route of not building, we need to do a good job of messaging as to why the library isn't being built, and re-iterate the |
|
Since it is unlikely that we will resolve the issues with using a newer Mesa library for the upcoming release, at the very least we need the Mesa patch. |
4d29a87 to
686d412
Compare
2 participants
Description
Resolves #20944
Type of change
[ ] New feature[ ] Documentation update[ ] OtherHow Has This Been Tested?
In fedora44 docker container, ran build_visit (default gcc version 16), compiled visit against generated third party libraries, and ran a cli test with good image generated.
On rzwhippet, ran build_visit using gcc13 with success. Compile visit (develop) against the generated third party libraries, and successfully ran the full regression suite in serial and parallel.
Checklist:
[ ] I have made corresponding changes to the documentation.[ ] I have added debugging support to my changes.[ ] I have added tests that prove my fix is effective or that my feature works.[ ] I have added new baselines for any new tests to the repo.[ ] I have NOT made any changes to protocol or public interfaces in an RC branch.