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

[Hanspeter Niederstrasser]

on macOS, there is no byteswap.h, so trying to build 1.0.13 fails with this error:

libemf.cpp:75:10: fatal error: 'byteswap.h' file not found
#include <byteswap.h>
         ^~~~~~~~~~~~

This is with system-clang. Switching to gnu-gcc-11 gets the same error.
Using Fink, we have gnulib from 2023 that includes byteswap.h. Borrowing the header from that lets it build. But with a newer gnulib from 2025, the build fails like this:

In file included from libemf.cpp:75:
./byteswap.h:23:3: error: "Please include config.h first."
 #error "Please include config.h first."
  ^
./byteswap.h:28:1: error: unknown type name '_GL_INLINE_HEADER_BEGIN'
_GL_INLINE_HEADER_BEGIN
^
./byteswap.h:34:1: error: expected unqualified-id
extern "C" {
^
./byteswap.h:113:1: error: use of undeclared identifier '_GL_INLINE_HEADER_END'
_GL_INLINE_HEADER_END
^

The config.h thing looks like a misdirection because the #error is inside this #if:

/* This file uses _GL_INLINE.  */
#if !_GL_CONFIG_H_INCLUDED
 #error "Please include config.h first."
#endif

So all related to GL_INLINE.

Is there another source of byteswap.h ?

[Allen Barnett]

It looks like bswap_32 is the only function used from byteswap.h. Is there an equivalent function on macOS? (https://man7.org/linux/man-pages/man3/bswap.3.html)

[Hanspeter Niederstrasser]

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

[Hanspeter Niederstrasser]

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 a straight #ifdefelse in the code

[Allen Barnett]

I have no recollection of why I put the #include in the middle of the
function; it seems dumb in retrospect. Your #ifdef/else at the top is OK
with me. I don't want to have to struggle with autotools anymore. I have no
way to test this on a mac, but if you send me a patch I'll apply it.

Are the new ARM-based macs run in little endian mode? Because the whole
bswap business is never invoked on little endian machines anyway.

On Fri, Apr 18, 2025 at 7:49 AM Hanspeter Niederstrasser nieder@users.sourceforge.net wrote:

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.</byteswap.h>

ifdef APPLE#include <libkern osbyteorder.h="">#define bswap_32(x) OSSwapInt32(x)#else#include <byteswap.h>#endif</byteswap.h></libkern>

So I had to move the whole #include chunk to the very top after #include
<climits></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 a
straight #ifdefelse in the code

---

[bugs:#6] https://sourceforge.net/p/libemf/bugs/6/ 1.0.13 build fails
with newer gnulib::byteswap.h

Status: open
Group: v1.0_(example)
Created: Fri Apr 18, 2025 10:38 AM UTC by Hanspeter Niederstrasser
Last Updated: Fri Apr 18, 2025 11:44 AM UTC
Owner: nobody

on macOS, there is no byteswap.h, so trying to build 1.0.13 fails with
this error:

libemf.cpp:75:10: fatal error: 'byteswap.h' file not found#include <byteswap.h> ^~~~~~~~~~~~</byteswap.h>

This is with system-clang. Switching to gnu-gcc-11 gets the same error.
Using Fink, we have gnulib from 2023 that includes byteswap.h. Borrowing
the header from that lets it build. But with a newer gnulib from 2025, the
build fails like this:

In file included from libemf.cpp:75:./byteswap.h:23:3: error: "Please include config.h first." #error "Please include config.h first." ^./byteswap.h:28:1: error: unknown type name '_GL_INLINE_HEADER_BEGIN'_GL_INLINE_HEADER_BEGIN^./byteswap.h:34:1: error: expected unqualified-idextern "C" {^./byteswap.h:113:1: error: use of undeclared identifier '_GL_INLINE_HEADER_END'_GL_INLINE_HEADER_END^

The config.h thing looks like a misdirection because the #error is inside
this #if:

/ This file uses _GL_INLINE. /

if !_GL_CONFIG_H_INCLUDED #error "Please include config.h first."

endif

So all related to GL_INLINE.

Is there another source of byteswap.h ?

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/libemf/bugs/6/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Scott Hannahs]

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 ?

[Hanspeter Niederstrasser]

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

[Scott Hannahs]

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.

[Scott Hannahs]

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

[Allen Barnett]

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

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

[Scott Hannahs]

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>

[Allen Barnett]

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