Issues with config.h

[Robert Kennedy]

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 <ryandesign at macports.org>
Sent: August 5, 2022 8:33 PM
To: Robert Kennedy <amtor at hotmail.com>
Cc: MacPorts Developers <macports-dev at 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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220806/553bbcd3/attachment-0001.htm>