[Oberon] clock_gettime / Traps on 32-bit Puppy Linux

[Michael Schierl]

Hello,


Am 02.08.2026 um 01:13 schrieb peter at easthope.ca:

>> Maybe xopup comes with the proper debugger tools that one could
>> use to trace this down, I just cannot run it due to not having an
>> XO.
> 
> Pardon ignorance but is the problem limited to this and possibly other
> Puppy Linuxes? Not affecting all 32 bit systems?

It is definitely not affecting all 32-bit systems. All my x86 Debian or 
Ubuntu systems (Being 32-bit or 64-bit) are not affected.

I don't have any other 32-bit X86 systems that have the 64-bit time_t 
patches applied, so I cannot definitely tell whether or how it would 
affect the bug.

To put it more clear, I don't have any other systems that are affected 
by this. On the other hand, I don't have any other systems based on 
eglibc either.

I have another Linux based on musl libc (Alpine) and - as expected - it 
does not start there at all, as musl uses a different LD loader. But you 
get a definitive error message and you can always use a chroot with a 
different C library to get around it.


So, to sum it up:

- Some linux versions (based on eglibc) and maybe others I am unaware of
   may run into this trap on thread exit.

- Some recent glibc versions may run into the issue of dlsym not being
   resolved for the 32-bit binary, where I posted a patch yesterday

- Some 32-bit glibc versions that were patched for 64-bit time_t may run
   into the issue that some clock related dlsym calls cannot be found,
   resulting in timer and time related functions to return zero. Debian
   is not affected as their official x86 32-bit build does not have these
   patches applied since they also negatively affect Wine and other
   legacy 32-bit programs. Dual libc would be technically feasible, but
   so far no distro tried it as far as I know. Not patched since as far
   as I can tell, it does not prevent A2 from running.


If you encounter a system that is affected by this bug, which runs on 
standard virtualization on Intel platform (e.g. QEMU, VirtualBox or 
Hyper-V) and that comes with precompiled debugging tools (gdb, edb), 
tell me, I might give it a try tracking down the real issue and provide 
a less-fairy-tale inspired fix :)


Regards,


Michael