Closed joncox123 closed 4 months ago
I don't have one of these CPUs, but SPARC is bigendian, and we are either failing to byteswap something in the file loaders, or more likely, failing to recognize that this system is bigendian, so all byte swapping fails.
SDL_PLATFORM_SOLARIS
is not present in SDL3/SDL_endian.h
, but __sparc__
is.
https://github.com/libsdl-org/SDL/blob/a4f962fd46b5b0b4ed9d5eb1e40a203cc0e5f422/include/SDL3/SDL_endian.h#L59-L88
Grepping in gcc, it defines __sparc__
when targeting netbsd (only in 32-bit mode),
and __sparc
when targeting vxworks.
I can see defines for __sparc_v8__
, __sparc_v9__
, __sparclet__
, __sparclite__
, __sparclite86x
, __supersparc__
and __leon__
in sparc.h.
There is a %(cpp_endian)
present in this file, but I think it is unset.
Solaris appears to have a <sys/byteorder.h>
system header, which eventually defines _BIG_ENDIAN
or _LITTLE_ENDIAN
as appropriate. I'll fix this up.
Okay, this should be good to go for both SDL2 and SDL3.
Sun/Oracle's compilers offer the best performance for SPARC processor platforms. The GNU toolset can be quite slow, especially if not using the
CFLAGS="-O3 -mcpu=ultrasparc3"
option, for example. With some work, I was able to make some modifications to SDL2-2.24.2 to get it to compile with Solaris Studio 12.4 compilers (e.g. the "cc" compiler), which is the last version from Oracle that natively supports the "older" UltraSPARC series of processors, like the IIIi.However, there is an issue when running the tests. It seems that, with some of my modifications, most things are now working, even
testfiles
andtestfilesystem
. However,loopaudio
andtestsprites2
, for example, cannot load any WAV or BMP file. It's able to open the file and read some bytes. For example, if I replace these resource files with a text file, it complains earlier in the loading process. However, even with valid WAV and BMP files, it says either the RIFF format is incorrect, or the pixel format is incorrect, for example.As strange as it seems, it looks like somehow compiling with Sun's
cc
compiler, even without any optimizations, breaks either some aspect of reading binary files or maybe comparing or processing the bytes in the binary files. It doesn't seem like a simple thing to debug.Am I missing anything obvious, and you please suggest some steps to take or things to look at?