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

Minimal compiler versions #2127

Open
edgarcosta opened this issue Dec 20, 2024 · 4 comments
Open

Minimal compiler versions #2127

edgarcosta opened this issue Dec 20, 2024 · 4 comments

Comments

@edgarcosta
Copy link
Member

edgarcosta commented Dec 20, 2024

In #2054 we noted that GCC 8 is no longer supported.
What is the minimal version required to build flint?
What about clang?
Or better, what features do we need?

Given this, where should we add this to the documentation?

Can we add this to the configure?

@edgarcosta
Copy link
Member Author

Also, on the same line of thought, should we try to consolidate INSTALL.md and doc/source/building.rst ?
At first pass, a symlink could do.

@albinahlback
Copy link
Collaborator

For inclusions of headers, we require that GNU compatible compilers is able to utilize attributes and macros from flint.h like FLINT_FORCE_INLINE. For compiling FLINT, we also require (but we strictly would not need to require) that GNU compatible compilers have all the pragmas we utilize. In the case of #2054, this is dangling pointer warnings.

We can still solve the issue by pushing something like

#if defined(__GNUC__) && __GNUC__ > SOME_NUMBER

and this goes for everything. We could support GCC 3 if we'd like to.

However, as a general note, I do not like the idea of having to support old compilers. If you build the newest release of a package, I think it is reasonable to expect that you have software that is somewhat new (say, at most two years old).

@albinahlback
Copy link
Collaborator

But, it would be good to document or clarify in the documentation.

@fredrik-johansson
Copy link
Collaborator

However, as a general note, I do not like the idea of having to support old compilers. If you build the newest release of a package, I think it is reasonable to expect that you have software that is somewhat new (say, at most two years old).

Though it's not clear that two years is a reasonable cutoff. Lots of people are on LTS distros way older than that, and there are institutional HPC clusters where the installed GCC version dates back to the geologic era of the volcanic sediments under the ground of the building where the computers are housed.

In my experience new compiler versions are more problematic anyway. The old versions have a known list of limitations; new versions always introduce creative new issues :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants