Recent changes to bugs

#7 1.0.13 build is broken on macOS due to using of Linux-specific header

Allen Barnett — Mon, 02 Feb 2026 12:42:57 -0000

Hi Sergey: Can you checkout the SVN HEAD. I applied a patch for this some months ago, but I never heard back from the submitter that it worked, so I never made a release. If you could test it, I would appreciate it.
Thanks,
Allen

1.0.13 build is broken on macOS due to using of Linux-specific header

Sergey Fedorov — Sun, 01 Feb 2026 19:39:54 -0000

libemf.cpp unconditionally includes Linux-specific byteswap.h, which breaks build on macOS.

#6 1.0.13 build fails with newer gnulib::byteswap.h

Allen Barnett — Sun, 27 Apr 2025 13:39:24 -0000

Hi Hanspeter and Scott: I have committed Hanspeter's patch to the repository (along with an update to the autotools/configure scripts). Please check that the svn HEAD (r101) compiles and passes regression on a macos machine. If it works, I'll make a release of 1.0.14 (if I can remember how, anyway).
I've been trying to remember why the endian-ness check is a run-time function and not a manifest attribute of the platform. But, I just can't recall what I was thinking in 2010 :-) I don't really want to have to update the autotools scripts.
Thanks for your input,
Allen

#6 1.0.13 build fails with newer gnulib::byteswap.h

Scott Hannahs — Wed, 23 Apr 2025 14:47:39 -0000

The bigEndian() check is a run time check. The #include <byteswap.h> is always included by the precompiler before the compile phase. It would have to be excluded by an #IFDEF or some other precompiler flag along with removing the actual call to bswap_32 also with an #IFDEF compiler directive.</byteswap.h>

#6 1.0.13 build fails with newer gnulib::byteswap.h

Hanspeter Niederstrasser — Tue, 22 Apr 2025 11:01:32 -0000

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 endian) was originally even trying to include byteswap.h since it's after the bigEndian() check in the code.

#6 1.0.13 build fails with newer gnulib::byteswap.h

Allen Barnett — Mon, 21 Apr 2025 13:30:38 -0000

Thanks for your suggestions. I will probably apply Hanspeter's #include change as that seems like the simplest way.

#6 1.0.13 build fails with newer gnulib::byteswap.h

Scott Hannahs — Sun, 20 Apr 2025 18:02:44 -0000

Or if you want to be specific to Apple clang, it has the following relefant defines to avoid including bytesswap.h?

#define __APPLE__ 1
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __LITTLE_ENDIAN__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_PDP_ENDIAN__ 3412

#6 1.0.13 build fails with newer gnulib::byteswap.h

Scott Hannahs — Sun, 20 Apr 2025 16:42:13 -0000

Shouldn't endianess be determined by configure and byteswap.h only included if the system is big-endiean? Usualy configure is used to determine endianess at compile time.

#6 1.0.13 build fails with newer gnulib::byteswap.h

Hanspeter Niederstrasser — Sun, 20 Apr 2025 11:13:45 -0000

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).

#6 1.0.13 build fails with newer gnulib::byteswap.h

Scott Hannahs — Sat, 19 Apr 2025 03:33:48 -0000

Yes, both the Arm and X86_64 Apple systems are little endian. Can we just trigger not to call byteswap or include it ifdef Apple ?