[MacPorts] #45570: gpsd: driver_rtcm2.c:125:2: error: #error Unknown endianness!
#45570: gpsd: driver_rtcm2.c:125:2: error: #error Unknown endianness! --------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.2 Keywords: powerpc | Port: gpsd --------------------------+-------------------------------- gpsd @3.5_4 is installed on my PowerBook G4 running Mac OS X 10.5 Leopard, but I cannot upgrade it to version @3.11_0 because: {{{ /usr/bin/gcc-4.2 -arch ppc -o driver_rtcm2.os -c -Os -arch ppc -D_GNU_SOURCE -Wextra -Wall -Wno-uninitialized -Wno-missing-field- initializers -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith -Wreturn-type -pthread -Wmissing- prototypes -Wmissing-declarations -O2 -fPIC driver_rtcm2.c driver_rtcm2.c:125:2: error: #error Unknown endianness! scons: *** [driver_rtcm2.os] Error 1 scons: building terminated because of errors. }}} -- Ticket URL: <https://trac.macports.org/ticket/45570> MacPorts <https://www.macports.org/> Ports system for OS X
#45570: gpsd: driver_rtcm2.c:125:2: error: #error Unknown endianness! ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.2 Resolution: | Keywords: powerpc Port: gpsd | ---------------------------+-------------------------------- Comment (by braumann@…): Though {{{driver_rtcm2.c}}} states in a comment that in case of such trouble the inclusion of {{{endian.h}}} might be considered, as I found there is no {{{endian.h}}} I instead have used {{{gcc49}}} for building: {{{ $ sudo port install gpsd configure.compiler=macports-gcc-4.9 ---> Computing dependencies for gpsd ---> Fetching archive for gpsd ---> Attempting to fetch gpsd-3.11_0.darwin_9.ppc.tbz2 from http://nue.de.packages.macports.org/macports/packages/gpsd ---> Attempting to fetch gpsd-3.11_0.darwin_9.ppc.tbz2 from http://lil.fr.packages.macports.org/gpsd ---> Attempting to fetch gpsd-3.11_0.darwin_9.ppc.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/gpsd ---> Fetching distfiles for gpsd ---> Verifying checksums for gpsd ---> Extracting gpsd ---> Applying patches to gpsd ---> Configuring gpsd ---> Building gpsd ---> Staging gpsd into destroot ---> Installing gpsd @3.11_0 ---> Activating gpsd @3.11_0 ---> Cleaning gpsd ---> Updating database of binaries ---> Scanning binaries for linking errors }}} Hope this will not give problems at runtime when linked with libraries having built with Xcode's {{{gcc42}}}. -- Ticket URL: <https://trac.macports.org/ticket/45570#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X
#45570: gpsd: driver_rtcm2.c:125:2: error: #error Unknown endianness! ---------------------------+-------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.2 Resolution: | Keywords: powerpc Port: gpsd | ---------------------------+-------------------------- Changes (by ryandesign@…): * owner: macports-tickets@… => ryandesign@… * status: new => assigned Comment: I don't recommend using a GCC port to build ports like gpsd that don't already call for it. OS X's endian.h is located in /usr/include/machine. gpsd knows to look there for it. -- Ticket URL: <https://trac.macports.org/ticket/45570#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X
#45570: gpsd @3.11: driver_rtcm2.c:125:2: error: #error Unknown endianness! ---------------------------+--------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.2 Resolution: fixed | Keywords: tiger leopard Port: gpsd | ---------------------------+--------------------------- Changes (by ryandesign@…): * keywords: powerpc => tiger leopard * status: assigned => closed * resolution: => fixed Comment: I fixed the problem in r135710. I'll report it to the developer of gpsd. -- Ticket URL: <https://trac.macports.org/ticket/45570#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X
#45570: gpsd @3.11: driver_rtcm2.c:125:2: error: #error Unknown endianness! ---------------------------+--------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.2 Resolution: fixed | Keywords: tiger leopard Port: gpsd | ---------------------------+--------------------------- Comment (by ryandesign@…): I may as well reproduce here what I sent to the developer, in case anyone is interested: ----- The problem is that on 10.5 only the following are defined: {{{ $ cpp -E -dM < /dev/null | grep -E '(BYTE|ENDIAN)' #define __BIG_ENDIAN__ 1 #define _BIG_ENDIAN 1 }}} That's on a PowerPC Mac; on an Intel Mac, presumably `__LITTLE_ENDIAN__` and `_LITTLE_ENDIAN` would both be defined to `1`. This runs afoul of the code in gpsd's driver_rtcm2.c which first does this: {{{ /* * BSD uses _BYTE_ORDER, and Linux uses __BYTE_ORDER. */ #if !defined( __BYTE_ORDER) && defined(_BYTE_ORDER) #define __BYTE_ORDER _BYTE_ORDER #endif #if !defined( __BIG_ENDIAN) && defined(_BIG_ENDIAN) #define __BIG_ENDIAN _BIG_ENDIAN #endif #if !defined( __LITTLE_ENDIAN) && defined(_LITTLE_ENDIAN) #define __LITTLE_ENDIAN _LITTLE_ENDIAN #endif }}} And then does this: {{{ /* * Darwin (Mac OS X) uses special defines. */ #if !defined( __BYTE_ORDER) && defined(__DARWIN_BYTE_ORDER) #define __BYTE_ORDER __DARWIN_BYTE_ORDER #endif #if !defined( __BIG_ENDIAN) && defined(__DARWIN_BIG_ENDIAN) #define __BIG_ENDIAN __DARWIN_BIG_ENDIAN #endif #if !defined( __LITTLE_ENDIAN) && defined(__DARWIN_LITTLE_ENDIAN) #define __LITTLE_ENDIAN __DARWIN_LITTLE_ENDIAN #endif }}} On 10.5, in the first block, on PowerPC, `__BIG_ENDIAN` gets set to `_BIG_ENDIAN`, i.e. `1` (or on Intel, `__LITTLE_ENDIAN` gets set to `_LITTLE_ENDIAN`, i.e. `1`), and `1` doesn't match either of the possible values of `__BYTE_ORDER` == `__DARWIN_BYTE_ORDER` (which is either `__DARWIN_BIG_ENDIAN` == `4321` or `__DARWIN_LITTLE_ENDIAN` == `1234`), which is where the error trips: {{{ #if __BYTE_ORDER == __BIG_ENDIAN #define WORDS_BIGENDIAN 1 #elif __BYTE_ORDER == __LITTLE_ENDIAN #undef WORDS_BIGENDIAN #else #error Unknown endianness! #endif /* __BYTE_ORDER */ }}} Assuming the BSD block is correct for BSD, the solution I propose is to reverse the order of these two blocks, putting the Darwin block before the BSD one. This allows the build to succeed on 10.5 at least. -- Ticket URL: <https://trac.macports.org/ticket/45570#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts