Hanspeter Niederstrasser

My patch to add libkern/OSByteOrder.h on Apple is attached. It's pretty simplistic and only checks for __APPLE__. As Scott says, an autotools method (AC_C_BIGENDIAN) could be 'better' (for some definition of better), but it seems overkill for this and then having to maintain configure.ac, etc. Would it improve it to wrap the entire set of includes on an #ifdef for __BIG_ENDIAN__ (does gcc have this macro or just __ORDER_BIG_ENDIAN__ )? The only thing I'm unclear on is why my x86_64 system (little...

Not a C person, but looking at the code, I'm confused as to what it's actually doing. It goes into the DWORD swab, and checks if the system is bigEndian(). If not, then it returns a. Should that then exit and not run bswap_32(a)? Or am I misunderstanding and it'll always return both a and the swapped a? I'm on x86_64, which is little endian, so I would expect it to not try to run bswap_32 (forgetting for the moment the header issue).

So I tried that, but if I put the following in place of the #include <byteswap.h> down on line 75, I get errors about function definitions before '{' tokens. #ifdef __APPLE__ #include <libkern/OSByteOrder.h> #define bswap_32(x) OSSwapInt32(x) #else #include <byteswap.h> #endif So I had to move the whole #include chunk to the very top after #include <climits> I don't know if it would be more appropriate to check for byteswap.h in configure and check for other possibilities if not found rather than...

Searching gives changes like this: #include <libkern/OSByteOrder.h> #define bswap_16(x) OSSwapInt16(x) #define bswap_32(x) OSSwapInt32(x) #define bswap_64(x) OSSwapInt64(x) Would need to #ifdef on __APPLE__ probably. https://stackoverflow.com/questions/41770887/cross-platform-definition-of-byteswap-uint64-and-byteswap-ulong

1.0.13 build fails with newer gnulib::byteswap.h

koi8-r test failure with encoding names

Yeah, it was the old jasper. Bumping to latest 4.2.2 fixes the pointer issue. Getting a separate implicit declaration of function 'xmlNanoFTPInit' error in coders/url.c, but will look through dependencies to make sure they're not at fault (libxml2-2.12.4) before filing. This ticket can be closed.

Thanks for the quick response. I'm running 1.900.1 because we thought libjasper had gone dead. But now it looks like it's been back for a while and we just never noticed. Is there a specific version that GraphicsMagick prefers (latest 4.x, 3.x, ???) ? thanks.