Dear Kim,
As mentioned on the ticket, this big-endian incompatibility does not
prevent the inclusion of primecount as an "experimental package" that I
still aim to achieve (the type of the package "experimental", "optional"
or "standard" is simply a flag). In practice "experimental" means "not
officially supported" and "less tested".

And as Dima mentioned, it would be simpler for SageMath to have
primecount supporting big-endian. We certainly do not want that a single
library prevents using SageMath on big-endian architecture.
Now, three questions for Sage developers:
- Who is testing a big-endian architecture?
- Are all optional packages big-endian compatible?
- Is it reasonable to ask for big-endian compatibility for
optional packages?
Vincent
PS: to discuss these kind of issues related to development, it is better
to use the other google group sage-devel.
On 13/03/2018 23:11, Dima Pasechnik wrote:

On Tuesday, March 13, 2018 at 9:41:50 PM UTC, Kim Walisch wrote:

Hi,
We all know that the big-endian CPU architecture is slowly dying,
some people even state that "Big-Endian is effectively dead".
So my question is: Does sagemath still support big-endian CPU
architectures like e.g. 32-bit Sparc?

We have recently more or less revived a SPARC Solaris 11 port of Sagemath.
So yes, please, make it both-endian...

--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.