Q3302ew Dies Immediately

[Blaine Bockholt]

Hello EW community,

  We recently upgraded to an Orange PI R1 Plus.  We have been using Orange Pis in our network for a few years now but once we updated to this new model, Q330EW no longer works.  The module dies immediately and never connects to our Q330s.  We are hoping someone has some insight about what is cause the problem.  I have attached our q3302ew.d and respective log files.  The module reaches the State change to 'Requesting Registration' and then the module dies.

Q3302EW.d:

#
# q3302ew configuration file
#

## The following items are typical Earthworm items

 ModuleId       MOD_Q3302EW     # module id for this module.  Make sure to
                                # add this to earthworm.h if it is not already
                                # there

 RingName       WAVE_RING       # transport ring to use for input/output,

 HeartbeatInt   60              # Heartbeat interval in seconds
                 
 LogFile        1               # If 0, don't write logfile;; if 1, do
                                # if 2, log to module log but not stderr/stdout

## The following items tell us how to talk to the Q330

IPAddress                IP_Address                # The Q330 IP address
BasePort                6330                        # The Q330 base port -
                                                #  5330 is the default base port
DataPort                1                        # Which Q330 dataport to use
SerialNumber                0x01000016A98FC931        # The serial number of the Q330
AuthCode                0x0                        # The Q330 auth code

## The following items may help traversing some firewalls

#SourcePortControl        9999        # UDP port to use as a source, when talking to
                                # the Q330's control port

#SourcePortData                9998        # UDP port to use as a source when talking to
                                # the Q330's data port


## The following items help control the log verbosity

LogLevel        sd, rm, vb, sm         # Comma seperated list of:
                                # sd - Logs Q330 status on connect
                                # cr - Logs command retries
                                # rm - Pings and sends a user message
                                #      to Q330 on connect/disconnect
                                # vb - Logs messages for items like
                                #      filter delays
                                # sm - Logs 800 series messages
                                # pd - Logs all packets sent/received

StatusInterval  240                # time in seconds between status updates


## The following items offer some control over connections

FailedRegistrationsBeforeSleep  5        # How many failed connection attempts
                                        # before we give it a break for a bit
MinutesToSleepBeforeRetry        3        # How long should that break be?


# optional setting
#RegistrationCyclesLimit        5         # defaults to 5 if not set, q3302ew exits after 5
                                        # failed registration attempts (restart by statmgr)

## Some options to control dutycycle
## comment out to disable


#Dutycycle_MaxConnectTime        10        # We'll disconnect after this many
                                        # minutes of being connected
#Dutycycle_BufferLevel                10        # Disconnect when the Q330's buffer is
                                        # this percentage filled.        
#Dutycycle_SleepTime                30        # Wait this many minutes before
                                        # connecting again, when we've stopped
                                        # for either of the above reasons

## Where should we keep our continuity files?
## These will be named: Q3302EW_cont_[dot_d_filename] and have '.bint'
## and '.binq' extensions.  
ContinuityFileDirectory        /tmp

Q3302ew.log:

-------------------------------------------------------

q3302ew_DVCI: startup at UTC_20220202_16:01:11

This program is using the MT-Safe version of logit.

-------------------------------------------------------

20220202_UTC_16:01:11 +++ Current Configuration:

20220202_UTC_16:01:11 --- ConfigFileName: Q330/q3302ew_DVCI.d

20220202_UTC_16:01:11 --- ModuleId: MOD_Q3302EW

20220202_UTC_16:01:11 --- RingName: WAVE_RING

20220202_UTC_16:01:11 --- RingKey: 1000

20220202_UTC_16:01:11 --- HeartbeatInt: 60

20220202_UTC_16:01:11 --- LogFile: 1

20220202_UTC_16:01:11 --- IPAddress: N/A

20220202_UTC_16:01:11 --- BasePort: 5330

20220202_UTC_16:01:11 --- DataPort: 1

20220202_UTC_16:01:11 --- SerialNumber: 0x010000069a412636

20220202_UTC_16:01:11 --- AuthCode: 0x0

20220202_UTC_16:01:11 --- ContinuityFileDirectory: /tmp

20220202_UTC_16:01:11 --- StatusInterval: 240

20220202_UTC_16:01:11 --- LogLevel: SD RM VB SM

20220202_UTC_16:01:11 --- SourcePortControl: 0

20220202_UTC_16:01:11 --- SourcePortData: 0

20220202_UTC_16:01:11 --- FailedRegistrationsBeforeSleep: 5

20220202_UTC_16:01:11 --- MinutesToSleepBeforeRetry: 3

20220202_UTC_16:01:11 --- Dutycycle_MaxConnectTime: 0

20220202_UTC_16:01:11 --- Dutycycle_SleepTime: 0

20220202_UTC_16:01:11 --- Dutycycle_BufferLevel: 0

20220202_UTC_16:01:11 +++ Lib330 Modules:

20220202_UTC_16:01:11 +++ LibClient:15 LibStrucs:18 LibTypes:13 LibMsgs:12

20220202_UTC_16:01:11 +++ LibSupport:7 LibStats:3 LibSlider:16 LibSeed:3

20220202_UTC_16:01:11 +++ LibSample:11 LibSampglob:8 LibSampcfg:16 LibMD5:3

20220202_UTC_16:01:11 +++ LibCvrt:2 LibCont:11 LibCompress:1 LibCmds:25

20220202_UTC_16:01:11 +++ LibVerbose:6 LibTokens:6 LibOpaque:4 LibLogs:3

20220202_UTC_16:01:11 +++ LibFilters:2 LibDetect:0 LibCtrlDet:3 LibArchive:5

20220202_UTC_16:01:11 +++ LibNetServ:6 LibDSS:6 Q330Types:4 Q330IO:13

20220202_UTC_16:01:11 +++ Q330Cvrt:11 LibPOC:3

20220202_UTC_16:01:11 +++ Initializing station thread

20220202_UTC_16:01:11 +++ Station thread created

20220202_UTC_16:01:11 20220202_UTC_16:01:11 +++ Starting registration with Q330

20220202_UTC_16:01:11 {212} Socket Opened on control port 60157

20220202_UTC_16:01:11 {212} Socket Opened on data port 49470

20220202_UTC_16:01:11 +++ State change to 'Requesting Registration'

-------------------------------------------------------

q3302ew_DVCI: startup at UTC_20220202_16:14:16

This program is using the MT-Safe version of logit.

-------------------------------------------------------

20220202_UTC_16:14:16 +++ Current Configuration:

20220202_UTC_16:14:16 --- ConfigFileName: Q330/q3302ew_DVCI.d

20220202_UTC_16:14:16 --- ModuleId: MOD_Q3302EW

20220202_UTC_16:14:16 --- RingName: WAVE_RING

20220202_UTC_16:14:16 --- RingKey: 1000

20220202_UTC_16:14:16 --- HeartbeatInt: 60

20220202_UTC_16:14:16 --- LogFile: 1

20220202_UTC_16:14:16 --- IPAddress: N/A

20220202_UTC_16:14:16 --- BasePort: 6330

20220202_UTC_16:14:16 --- DataPort: 1

20220202_UTC_16:14:16 --- SerialNumber: 0x01000016A98FC931

20220202_UTC_16:14:16 --- AuthCode: 0x0

20220202_UTC_16:14:16 --- ContinuityFileDirectory: /tmp

20220202_UTC_16:14:16 --- StatusInterval: 240

20220202_UTC_16:14:16 --- LogLevel: SD RM VB SM

20220202_UTC_16:14:16 --- SourcePortControl: 0

20220202_UTC_16:14:16 --- SourcePortData: 0

20220202_UTC_16:14:16 --- FailedRegistrationsBeforeSleep: 5

20220202_UTC_16:14:16 --- MinutesToSleepBeforeRetry: 3

20220202_UTC_16:14:16 --- Dutycycle_MaxConnectTime: 0

20220202_UTC_16:14:16 --- Dutycycle_SleepTime: 0

20220202_UTC_16:14:16 --- Dutycycle_BufferLevel: 0

20220202_UTC_16:14:16 +++ Lib330 Modules:

20220202_UTC_16:14:16 +++ LibClient:15 LibStrucs:18 LibTypes:13 LibMsgs:12

20220202_UTC_16:14:16 +++ LibSupport:7 LibStats:3 LibSlider:16 LibSeed:3

20220202_UTC_16:14:16 +++ LibSample:11 LibSampglob:8 LibSampcfg:16 LibMD5:3

20220202_UTC_16:14:16 +++ LibCvrt:2 LibCont:11 LibCompress:1 LibCmds:25

20220202_UTC_16:14:16 +++ LibVerbose:6 LibTokens:6 LibOpaque:4 LibLogs:3

20220202_UTC_16:14:16 +++ LibFilters:2 LibDetect:0 LibCtrlDet:3 LibArchive:5

20220202_UTC_16:14:16 +++ LibNetServ:6 LibDSS:6 Q330Types:4 Q330IO:13

20220202_UTC_16:14:16 +++ Q330Cvrt:11 LibPOC:3

20220202_UTC_16:14:16 +++ Initializing station thread

20220202_UTC_16:14:16 +++ Station thread created

20220202_UTC_16:14:16 20220202_UTC_16:14:16 +++ Starting registration with Q330

20220202_UTC_16:14:16 {212} Socket Opened on control port 54473

20220202_UTC_16:14:16 {212} Socket Opened on data port 43070

20220202_UTC_16:14:16 +++ State change to 'Requesting Registration'

-------------------------------------------------------

q3302ew_DVCI: startup at UTC_20220202_16:35:49

This program is using the MT-Safe version of logit.

-------------------------------------------------------

20220202_UTC_16:35:49 +++ Current Configuration:

20220202_UTC_16:35:49 --- ConfigFileName: Q330/q3302ew_DVCI.d

20220202_UTC_16:35:49 --- ModuleId: MOD_Q3302EW

20220202_UTC_16:35:49 --- RingName: WAVE_RING

20220202_UTC_16:35:49 --- RingKey: 1000

20220202_UTC_16:35:49 --- HeartbeatInt: 60

20220202_UTC_16:35:49 --- LogFile: 1

20220202_UTC_16:35:49 --- IPAddress: N/A

20220202_UTC_16:35:49 --- BasePort: 6330

20220202_UTC_16:35:49 --- DataPort: 1

20220202_UTC_16:35:49 --- SerialNumber: 0x01000016A98FC931

20220202_UTC_16:35:49 --- AuthCode: 0x0

20220202_UTC_16:35:49 --- ContinuityFileDirectory: /tmp

20220202_UTC_16:35:49 --- StatusInterval: 240

20220202_UTC_16:35:49 --- LogLevel: SD RM VB SM

20220202_UTC_16:35:49 --- SourcePortControl: 0

20220202_UTC_16:35:49 --- SourcePortData: 0

20220202_UTC_16:35:49 --- FailedRegistrationsBeforeSleep: 5

20220202_UTC_16:35:49 --- MinutesToSleepBeforeRetry: 3

20220202_UTC_16:35:49 --- Dutycycle_MaxConnectTime: 0

20220202_UTC_16:35:49 --- Dutycycle_SleepTime: 0

20220202_UTC_16:35:49 --- Dutycycle_BufferLevel: 0

20220202_UTC_16:35:49 +++ Lib330 Modules:

20220202_UTC_16:35:49 +++ LibClient:15 LibStrucs:18 LibTypes:13 LibMsgs:12

20220202_UTC_16:35:49 +++ LibSupport:7 LibStats:3 LibSlider:16 LibSeed:3

20220202_UTC_16:35:49 +++ LibSample:11 LibSampglob:8 LibSampcfg:16 LibMD5:3

20220202_UTC_16:35:49 +++ LibCvrt:2 LibCont:11 LibCompress:1 LibCmds:25

20220202_UTC_16:35:49 +++ LibVerbose:6 LibTokens:6 LibOpaque:4 LibLogs:3

20220202_UTC_16:35:49 +++ LibFilters:2 LibDetect:0 LibCtrlDet:3 LibArchive:5

20220202_UTC_16:35:49 +++ LibNetServ:6 LibDSS:6 Q330Types:4 Q330IO:13

20220202_UTC_16:35:49 +++ Q330Cvrt:11 LibPOC:3

20220202_UTC_16:35:49 +++ Initializing station thread

20220202_UTC_16:35:49 +++ Station thread created

20220202_UTC_16:35:49 20220202_UTC_16:35:49 +++ Starting registration with Q330

20220202_UTC_16:35:50 {212} Socket Opened on control port 36543

20220202_UTC_16:35:50 {212} Socket Opened on data port 35046

20220202_UTC_16:35:50 +++ State change to 'Requesting Registration'

[Paul Friberg]

So to be clear, you are running EW on a new Raspberry Pi and using a "known to work q3302ew.d" that you have tested on the same network with different Pi computers (earlier release of this Orange PI product)? It must be something in the newer OS version then that is blocking the UDP connections to the Q330. It should work identically if nothing is different about the specific chip set being used on the two versions. It could be a firewall is my guess.

Paul

--
--
You received this message because you are subscribed to the Google
Groups "Earthworm Community Forum" group.
 
To post to this group, send an email to earthwo...@googlegroups.com
 
To unsubscribe from this group, send an email to
earthworm_for...@googlegroups.com
 
For more options, visit this group at
http://groups.google.com/group/earthworm_forum?hl=en

---
You received this message because you are subscribed to the Google Groups "Earthworm Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to earthworm_for...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/earthworm_forum/ee43dac1-32b6-45f2-8f69-29f066a5d5e2n%40googlegroups.com.

--

===================================
Paul Friberg   p.fr...@isti.com
CEO/Seismologist
ISTI==Instrumental Software Technologies, Inc.
Phone +1.518.602.0001  

[jonrusho]

Was a solution to this ever identified?  I'm running into a similar problem with q3302ew with a known-good .d file.

Environment:  Raspberry Pi 4 or Raspberry Pi 5

Distro: Raspberry Pi OS, 64-bit.  Trixie port.  Lite version

GCC: 14.2.0 (debian 14.2.0-19)

EW: 7.10.1, built from source.

Tail end of the output when using gdb on a Pi 5:

20260316_UTC_23:13:35 +++ Initializing station thread
[New Thread 0x7ffff7d1b1a0 (LWP 1233)]
20260316_UTC_23:13:35 +++ Station thread created
[New Thread 0x7ffff6d0b1a0 (LWP 1234)]
20260316_UTC_23:13:35 20260316_UTC_23:13:35 +++ Starting registration with Q330
20260316_UTC_23:13:35 {212} Socket Opened  on control port 59860
20260316_UTC_23:13:35 {212} Socket Opened  on data port 44480
20260316_UTC_23:13:35 +++ State change to 'Requesting Registration'

Thread 2 "q3302ew" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7d1b1a0 (LWP 1233)]
gcrccalc (crctable=0x5555555ffd40, p=0x55602223 <error: Cannot access memory at address 0x55602223>, len=16) at libstrucs.c:290
290       temp = ((crc shr 24) xor *p++) and 255 ;
(gdb) 

Running it as root, to get around possible permission issues, it has the same behavior.

q3302ew built from source, v7.10, on 32-bit Buster on a Pi 3 works properly.

My next steps will be to test on Bookworm under both 32-bit and 64-bit builds, unless someone has an easy solution.

Thanks

--jon

[Jon Rusho]

Addendum:

Bookworm/64-bit and Trixie/64-bit both seg fault with the q3302ew module, built from source.

Trixie/32-bit does work.  So, rather than a kernel issue, I'm wondering if this is something like an int vs. long int size problem that crops up with the q3302ew module on 64-bit systems.

--jon

To view this discussion visit https://groups.google.com/d/msgid/earthworm_forum/807f7575-766f-4ec8-9623-ecfc9482ff9en%40googlegroups.com.

--

===================================
Jon Rusho
Senior Seismic Network Engineer
University of Utah Seismograph Stations

jon.uu...@gmail.com
801-414-9537 (cell)

[Larry Baker]

Jon,

Any chance you can get a traceback (I think gdb calls it a backtrace, bt)?  I think the problem is that lib330 does not properly define the size of a pointer on 64-bit ARM.

lib330 identifies the platform and defines the appropriate data types in src/libsrc/lib330/platform.h.  There is no ARM64 platform type.  There is an ARM32 platform type, which is defined for any ARM32/64 platform when the compiler defines (__arm__) and (linux):

#if defined(BALER44) || (defined(__arm__) && defined(linux))

  #define ARM_UNIX32

#endif

That causes the ARM32/64 platform types to be defined using the same block of code as for x86-32 and x86-64 (isn't there a SPARC-64 too?):

#elif defined(X86_UNIX32) || defined(SPARC_UNIX32) || defined(X86_UNIX64) || defined(ARM_UNIX32)

The only conditional within that block defines the size of a pntrint (pointer to int) according to the platform macro, which just so happens to depend on whether the platform is properly recognized as 32-bit or 64-bit:

#if defined(X86_UNIX64) || defined(__x86_64__)

#define pntrint uint64_t /* 64 bit unsigned, same size as pointer */

#else

#define pntrint uint32_t /* 32 bit unsigned, same size as pointer */

#endif

Google AI tells us:

Data Models (LP64 vs. ILP64): ARM64 typically uses the LP64 data model (Long/Pointer = 64-bit, Integer = 32-bit) on Linux and Android, which is standard for most 64-bit systems. ILP64 (Integer/Long/Pointer = 64-bit) is less common and usually not the default.

I.e., on ARM64, a pointer is 64 bits.  Since lib330 has no ARM64 platform type, the logic in platform.h causes the wrong definition of a pntrint on ARM64.

gcrccalc() is in src/libsrc/lib330/libstrucs.c:

longint gcrccalc (crc_table_type *crctable, pbyte p, longint len)

The memory access error occurs referencing *p.  There's nothing special about "pbyte p" in the argument list: pbyte is "typedef byte *pbyte".  What really matters is how p is passed by the caller.  I searched src/libsrc/lib330/*.c for calls to gcrccalc().  Sure enough, most calls cast p using (pntrint), such as this:

thiscrc = gcrccalc (addr(q330->crc_table), (pointer)((pntrint)psave + 4), actual - 4) ;

The fix is to add ARM64 support to platform.h by 1) discriminating between ARM32 and ARM64 to define either ARM_UNIX32 or ARM_UNIX64, and 2) include ARM64 in the conditional that defines pntrint, such as: #if defined(X86_UNIX64) || defined(__x86_64__) || defined(ARM_UNIX64)

Larry Baker

larry...@stanfordalumni.org

To view this discussion visit https://groups.google.com/d/msgid/earthworm_forum/CAAqUwAhOBHVap5q8xJ700OpPQfdQ4gAKsz%3DYuNDjt0mdAiXzew%40mail.gmail.com.

[Jon Rusho]

Here's the backtrace from gdb:

20260317_UTC_02:27:31 {212} Socket Opened  on data port 60147
20260317_UTC_02:27:31 +++ State change to 'Requesting Registration'

Thread 2 "q3302ew" received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0x7fff737eb1a0 (LWP 1081)]
gcrccalc (crctable=0x5555f667fd40, p=0xf6682223 <error: Cannot access memory at address 0xf6682223>, len=16) at libstrucs.c:290

290      temp = ((crc shr 24) xor *p++) and 255 ;

(gdb) bt
#0  gcrccalc (crctable=0x5555f667fd40, p=0xf6682223 <error: Cannot access memory at address 0xf6682223>, len=16) at libstrucs.c:290
#1  0x00005555e3cbb9dc in lib_send_next_cmd (q330=0x5555f667c0c0) at libcmds.c:364
#2  0x00005555e3cbbe9c in new_cmd (q330=0x5555f667c0c0, ncmd=16 '\020', sz=8) at libcmds.c:485
#3  0x00005555e3cbc3ec in lib_continue_registration (q330=0x5555f667c0c0) at libcmds.c:654
#4  0x00005555e3cbc4a8 in lib_start_registration (q330=0x5555f667c0c0) at libcmds.c:692
#5  0x00005555e3cbebcc in lib_timer (q330=0x5555f667c0c0) at libcmds.c:1587
#6  0x00005555e3cc087c in libthread (p=0x5555f667c0c0) at libstrucs.c:629
#7  0x00007fff73895ef8 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
#8  0x00007fff738fde0c in ?? () from /lib/aarch64-linux-gnu/libc.so.6

[Larry Baker]

Jon,

I not only fixed the recognition of ARM64 Linux, but I also added recognition (I hope) of Apple M1, M2, etc (ARM64) silicon.

Try the attached patch to src/libsrc/lib330/platform.h:

Put the patch in your generic Earthworm top-level folder, i.e., mine is /Users/baker/Desktop/Software/Earthworm:

$ cd /Users/baker/Desktop/Software/Earthworm

$ cp <mail folder>/lib330.patch ./

cd to the Earthworm V7.10.1 directory:

$ cd earthworm_7.10.1

Make a copy of the original platform.h, just in case:

$ cp src/libsrc/lib330/platform.h <somewhere safe>

Patch src/libsrc/lib330/platform.h (it should create a backup src/libsrc/lib330/platform.h.orig):

$ patch -b <../lib330.patch

Rebuild your Earthworm modules.

Let me know if it works for you on your Raspberry Pi and I'll send it to ISTI to test it on Apple silicon too.

Larry Baker
larry...@stanfordalumni.org

[Larry Baker]

A change to platform.h I think is worth considering is to use the typedef for uintptr_t that is already in stdint.h.  That is, unconditionally "#define pntrint uintptr_t" in platform.h.  Admittedly, uintptr_t is optional.  But, there could be conditional code to invoke the logic currently in platform.h with a new CPP macro that could be added to the CC command, if necessary.  If the compiler/OS stdint.h defines uintptr_t, why try to guess what is already there for you to use?

Larry Baker
larry...@stanfordalumni.org

<lib330.patch>

[Larry Baker]

Paul,

Have a look at this patch I sent this past week to Jon Rusho at Univ of Utah (jon....@gmail.com).  This thread originated four years ago with Blaine Bockholt (blaineb...@gmail.com) on Feb 2, 2022.  I diagnosed and fixed the problem Jon reported he was having running q3302ew on a 64-bit Raspberry Pi.  I don't know if it also fixes Blaine's problem.  Jon tested his own patch based on my diagnosis.

Attached is a my patch to src/libsrc/lib330/platform.h.  I asked Jon to test my patch, but I haven't heard back from him yet.  I have no way of testing it.  Please test this patch and merge it into the lib330 source.

As I said in my last email in this thread, a change to platform.h that is worth considering is to use the typedef for uintptr_t that is already in stdint.h.  That is, unconditionally "#define pntrint uintptr_t" in platform.h.  (N.b., all these type definitions in platform.h should really be typedef's.)  It would completely eliminate the need to determine the size of a pointer on any platform Earthworm supports.  uintptr_t is an optional feature in stdint.h, which was introduced in C99.  GCC has included for uintptr_t support since the late 1990's to early 2000's.  clang has included uintptr_t support since at least 2019.  MSVC has supported stdint.h with uintptr_t since 2010.  If the compiler/OS stdint.h supports uintptr_t, why try to guess what it should be when it is always correctly declared there?

By the way, lib660 has the same bug.  And lib660 also fails to ever define X86_UNIX64 on an x86-64 machine, which, I think accounts for the addition of  "|| defined(__x86_64__)" when lib660 defines PNTRINT (I fixed that in lib330).  And Apple uses "|| defined (__arm64__)" in <machine/types.h>, not "|| defined(__aarch64__)" as in lib660 (I added the Apple test to lib330).

Thank you,

Larry Baker
larry...@stanfordalumni.org

Begin forwarded message:

[Paul Friberg]

If someone (Jon?) can confirm the patch works, we'll include it in the next release build.  Thanks Larry 

===================================
Paul Friberg   p.fr...@isti.com
CEO/Seismologist
ISTI==Instrumental Software Technologies, Inc.
Phone +1.518.602.0001  

[Jon Rusho]

I'll test it and let you know.

[Larry Baker]

All's well, go for it!

The platform-v1.h and platform-v2.h I sent previously both solve the problem of the SIGSEGV on ARM64 hardware.

I recommend using platform-v2.h, since it relies on the compiler to properly #define pntrint uintptr_t (from C99 #include <stdint.h>) no matter what.

The same fix can be made to q660util/platform.h (and remove #define ALIGN_64 for Apple 64-bit processors; it's not used anywhere).

For both lib330 and lib660, I think platform.h can be further simplified to separate definitions of machine characteristics (i.e., endianness) to use common semantic macros, if available, otherwise compiler-supplied arch names (as is done now), separate from the OS API includes.  It seems these days the only API conditional that matters is _WIN32/_WIN64 vs all others (some flavor of *nix).  I don't think a separate #ifdef __APPLE__ section is needed.

Larry Baker
larry...@stanfordalumni.org

On Mar 29, 2026, at 9:04 PM, Larry Baker <larry...@stanfordalumni.org> wrote:

Jon and Paul,

I tested all three versions of platform.h on Windows and recorded the results, and I just finished doing the same on my new MacBook Air M4.  Attached is my (final, I believe) writeup.

Tomorrow I will go through the writeup and repeat every step to verify the results.  And I will make sure the three versions of platform.h on my four different laptops are identical.  (I am sure they are.)

I'll let you know after that tomorrow.

Cheers,

Larry Baker
larry...@stanfordalumni.org

On Mar 27, 2026, at 2:32 PM, Larry Baker <larry...@stanfordalumni.org> wrote:

I should have mentioned that I have not yet tried to build lib330 on Windows.  I have a Windows 11 laptop that I have installed MS Visual C Command Line version.  I'll try that before I set up my new MacBook Air M4.

Larry Baker
larry...@stanfordalumni.org

On Mar 27, 2026, at 2:24 PM, Larry Baker <larry...@stanfordalumni.org> wrote:

Jon,

Here are three versions of platform.h:

  platform-orig.h - the original lib330 version in EW 10.1 that failed for your Raspberry Pi ARM64 build

  platform-v1.h - modified to add support for ARM64 (Linux and macOS), correct definition of X86_UNIX64, #undef local macros not used elsewhere in lib330.a

  platform-v2.h - modified to #include <stdint.h> and always #define pntrint uintptr_t (let the compiler figure out the right size pntrint)

The "lib330 tests.txt" file has all the tests I ran to build lib330.a for macOS x86_64 (ARM64 M4 to be supplied after I set up my new MacBook Air M4), Linux x86_64 32-bit and 64-bit builds, and Linux x86_64 ARM and ARM64 cross builds.

I thank platform-v2.h is the appropriate one to use.

I'll get back to you with the results of my macOS ARM64 M4 build to let you know if any modifications to these files are needed.

Larry Baker
larry...@stanfordalumni.org

<platform-orig.h>

<platform-v1.h>

<platform-v2.h>

<lib330 tests.txt>

On Mar 26, 2026, at 7:54 PM, Larry Baker <larry...@stanfordalumni.org> wrote:

Jon,

I already found out that the updated platform.h won't work for you.  It turns out __arm__ is not defined for ARM64, only __aarch64__ is.  I'm working on setting up a test environment to cross-compile for ARM/ARM64 on my Linux laptop.  I have to get rid of Ricky first (they don't support cross-compiling for ARM) and install Ubuntu.  I hope to have my testing done and the updated platform.h's out the door to you no later than this weekend.

Larry Baker
larry...@stanfordalumni.org

On Mar 26, 2026, at 12:56 PM, Larry Baker <larry...@stanfordalumni.org> wrote:

Hey Jon,

Let me make two platform.h's for you to try.  I want to make sure I can confirm the old platform.h fails on ARM64 and then I want to try one like I sent you already and one that disposes of the conditional #define's and uses a #define to the standard C stdint.h uintptr_t.  I'll make sure the code compiles without any errors and with the exact same warnings for the string pointer mismatches.  Then you can test the executables and let us know how it goes.

I'll be in touch.

<lib330 tests.txt>

[Larry Baker]

All's well, go for it!

*** I forgot to mention that there is an updated version of my writeup attached ***

The platform-v1.h and platform-v2.h I sent previously both solve the problem of the SIGSEGV on ARM64 hardware.

I recommend using platform-v2.h, since it relies on the compiler to properly #define pntrint uintptr_t (from C99 #include <stdint.h>) no matter what.

The same fix can be made to q660util/platform.h (and remove #define ALIGN_64 for Apple 64-bit processors; it's not used anywhere).

For both lib330 and lib660, I think platform.h can be further simplified to separate definitions of machine characteristics (i.e., endianness) to use common semantic macros, if available, otherwise compiler-supplied arch names (as is done now), separate from the OS API includes.  It seems these days the only API conditional that matters is _WIN32/_WIN64 vs all others (some flavor of *nix).  I don't think a separate #ifdef __APPLE__ section is needed.

Larry Baker
larry...@stanfordalumni.org

On Mar 29, 2026, at 9:04 PM, Larry Baker <larry...@stanfordalumni.org> wrote:

Jon and Paul,

I tested all three versions of platform.h on Windows and recorded the results, and I just finished doing the same on my new MacBook Air M4.  Attached is my (final, I believe) writeup.

Tomorrow I will go through the writeup and repeat every step to verify the results.  And I will make sure the three versions of platform.h on my four different laptops are identical.  (I am sure they are.)

I'll let you know after that tomorrow.

Cheers,

Larry Baker
larry...@stanfordalumni.org

On Mar 27, 2026, at 2:32 PM, Larry Baker <larry...@stanfordalumni.org> wrote:

I should have mentioned that I have not yet tried to build lib330 on Windows.  I have a Windows 11 laptop that I have installed MS Visual C Command Line version.  I'll try that before I set up my new MacBook Air M4.

Larry Baker
larry...@stanfordalumni.org

On Mar 27, 2026, at 2:24 PM, Larry Baker <larry...@stanfordalumni.org> wrote:

Jon,

Here are three versions of platform.h:

  platform-orig.h - the original lib330 version in EW 10.1 that failed for your Raspberry Pi ARM64 build

  platform-v1.h - modified to add support for ARM64 (Linux and macOS), correct definition of X86_UNIX64, #undef local macros not used elsewhere in lib330.a

  platform-v2.h - modified to #include <stdint.h> and always #define pntrint uintptr_t (let the compiler figure out the right size pntrint)

The "lib330 tests.txt" file has all the tests I ran to build lib330.a for macOS x86_64 (ARM64 M4 to be supplied after I set up my new MacBook Air M4), Linux x86_64 32-bit and 64-bit builds, and Linux x86_64 ARM and ARM64 cross builds.

I thank platform-v2.h is the appropriate one to use.

I'll get back to you with the results of my macOS ARM64 M4 build to let you know if any modifications to these files are needed.

Larry Baker
larry...@stanfordalumni.org

<platform-orig.h>

<platform-v1.h>

<platform-v2.h>

<lib330 tests.txt>

On Mar 26, 2026, at 7:54 PM, Larry Baker <larry...@stanfordalumni.org> wrote:

Jon,

I already found out that the updated platform.h won't work for you.  It turns out __arm__ is not defined for ARM64, only __aarch64__ is.  I'm working on setting up a test environment to cross-compile for ARM/ARM64 on my Linux laptop.  I have to get rid of Ricky first (they don't support cross-compiling for ARM) and install Ubuntu.  I hope to have my testing done and the updated platform.h's out the door to you no later than this weekend.

Larry Baker
larry...@stanfordalumni.org

On Mar 26, 2026, at 12:56 PM, Larry Baker <larry...@stanfordalumni.org> wrote:

Hey Jon,

Let me make two platform.h's for you to try.  I want to make sure I can confirm the old platform.h fails on ARM64 and then I want to try one like I sent you already and one that disposes of the conditional #define's and uses a #define to the standard C stdint.h uintptr_t.  I'll make sure the code compiles without any errors and with the exact same warnings for the string pointer mismatches.  Then you can test the executables and let us know how it goes.

I'll be in touch.

<lib330 tests.txt>