Thanks Ryan.

I am torn whether to keep WORDS_BIGENDIAN in the code.  Perhaps, I will just 
leave it in the code and see if anyone reports bugs.

This code was compiled my Metakine into a ppc/x86 FAT binary and run without 
issues for many years.
So I suspect the WORDS_BIGENDIAN macro was never used in the code since as you 
pointed out Intel Macs are little little-endian.

Rob

________________________________
From: Ryan Schmidt <ryandes...@macports.org>
Sent: August 5, 2022 8:33 PM
To: Robert Kennedy <am...@hotmail.com>
Cc: MacPorts Developers <macports-dev@lists.macports.org>
Subject: Re: Issues with config.h

On Aug 5, 2022, at 16:43, Robert Kennedy wrote:
>
> I have also patched config.h to address the ARCH issue.  It now reads:
>
> #ifndef LINUX
>           #if defined(__ppc__) || defined(__ppc64__)
>                 #define ARCH_PPC
>           #elif defined(__i386__)
>                 #define ARCH_X86
>           #elif defined(__x86_64__)
>               #define ARCH_X86_64
>         #elif defined ((__arm64__) && defined(__APPLE__)) || (__aarch64__)
>             #define ARCH_ARM64
>         #else
>             #define ARCH_X86
>         #endif
> #endif
>
> But it looks like ARCH_PPC, ARCH_X86 is not used anywhere in the code.  It 
> might have been easier to just remove all this code.

Sure, that's how you could write defines for various architectures, but if 
they're not used in the code there's no point.

I see that ARCH_PPC is used in mpeg2dec/mpeg2_internal.h. I agree I don't see 
anywhere that ARCH_X86 is used.

> I will check whether the code uses WORDS_BIGENDIAN.  If not, I will just 
> patch out the problematic code:
>
> #ifndef LINUX
> #define WORDS_BIGENDIAN 1
> #endif

I agree WORDS_BIGENDIAN is not used anywhere within this project's code, 
however it is a standard define name and I don't know whether it is used in any 
system headers that this project's code might be including.

Code that process endianness incorrectly will probably still compile and run 
but will generate incorrect data. So just the fact that it compiles doesn't 
mean it's right.


> My portfile already had PortGroup           makefile 1.0 so there was no need 
> to add it.

Ah, yes, I missed that. As you've now found, using the makefile portgroup means 
there's no need for you to list "use_configure no"; the fact that you had still 
listed "use_configure no" lead me to the incorrect assumption that you had not 
used the makefile portgroup.



Reply via email to