Hi, ================================= Starting A2 system. Unix.Dlsym: entry 'clock_gettime' not found Unix.Dlsym: entry 'clock_getres' not found GC mode : metadata LinuxA2 Gen. 32-bit, Apr 19 2023 2026/07/05 06:04 Trap 11 (Segmentation violation) ================================= Clock access in an older Linux differs from contemporary Linux. I wonder whether Linux.Unix.Mod can determine what is available before invoking something certain to fail. Then invoke something which works. Linux.Unix.Mod has this. Dlsym( libc, "clock_gettime", ADDRESSOF(clock_gettime) ); ... clock_gettime- : PROCEDURE {C} (clk_id: INTEGER; tp: ADDRESS): INTEGER; Ideas? Thanks, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 778 508 0020 <= decommissioning Bcc: peter at e a s t h o p e dot c a projects: en.wikibooks.org/wiki/User:PeterEasthope
Hello Peter, Am 11.07.2026 um 17:09 schrieb peter@easthope.ca:
Hi, ================================= Starting A2 system. Unix.Dlsym: entry 'clock_gettime' not found Unix.Dlsym: entry 'clock_getres' not found GC mode : metadata
LinuxA2 Gen. 32-bit, Apr 19 2023 2026/07/05 06:04
Trap 11 (Segmentation violation) =================================
Clock access in an older Linux differs from contemporary Linux. I wonder whether Linux.Unix.Mod can determine what is available before invoking something certain to fail. Then invoke something which works.
I wonder whether anybody thinks that a segfault happening several lines of output after a dlsym warning have anything to do with that dlsym being failing. (I would assume the likelyhood to be so to be very minimal). Anyway, DLSym can fail gracefully, resulting in the procedure pointer to be NIL. Which is checked in some places but not all, but I did not quickly find a way any of those paths to be called in the startup sequence. Still, your clock and timer outputs will be wrong, so you'd need to fix it if it disturbs you. And in case your TRAP is caused by something else, you still need to find and fix that of course, to get the system running.
From A2/source/Linux.Unix.Mod,
CLOCK_MONOTONIC* = 1; CLOCK_MONOTONIC_RAW* = 4; CLOCK_PROCESS_CPUTIME_ID* = 2; CLOCK_REALTIME* = 0; CLOCK_THREAD_CPUTIME_ID* = 3; ... clock_gettime- : PROCEDURE {C} (clk_id: INTEGER; tp: ADDRESS): INTEGER; clock_getres- : PROCEDURE {C} (clk_id: INTEGER; res: ADDRESS): INTEGER;
Web searches reported that the Linux kernel introduced CLOCK_MONOTONIC in 2.5.63, CLOCK_MONOTONIC_RAW in 2.6.28, CLOCK_PROCESS_CPUTIME_ID in 2.6.12, CLOCK_REALTIME in 2.6.0, CLOCK_THREAD_CPUTIME_ID in 2.6.12, clock_gettime in 2.6 and clock_getres in 2.6.
Whereas in a 32 bit machine here, uname -a reports, Linux puppypc 2.6.35.13_xo1.5-20110713.2219.olpc.da7074b_Puppy .
So the clock calls should work.
Ideas?
The exported syscalls of a kernel have nothing to do with the exported symbols of your C library. On 32-bit systems which are compiled against 64-bit time_t (to work around Y2038 bug), glibc's export is called "__clock_gettime64" instead of "clock_gettime", and its ABI signature changed. You can try to dlsym both and call whichever is non-NIL.
Thanks, ... P.
Hope that helps, Michael
Hi Peter The procedure variables offered by Linux.Unix.Mod should (but possibly don't) form the minimal set of procedures required to run the system. I wonder where the system actually traps. Do you have more output after that Trap 11 line? Maybe in this case an easy fix is to offer a different Timer module? Because the kernel does not really seem to use the procedure variables you referred to (as far as I can see this). If this fix is not acceptable, what can be done is offering a proper procedure Unix.clock_gettime and check the availability of the clock_gettime_x (or whatever it would then be called internally) or call alternative functions from there. Kind regards Felix On 7/11/26 17:09, peter@easthope.ca wrote:
Hi, ================================= Starting A2 system. Unix.Dlsym: entry 'clock_gettime' not found Unix.Dlsym: entry 'clock_getres' not found GC mode : metadata
LinuxA2 Gen. 32-bit, Apr 19 2023 2026/07/05 06:04
Trap 11 (Segmentation violation) =================================
Clock access in an older Linux differs from contemporary Linux. I wonder whether Linux.Unix.Mod can determine what is available before invoking something certain to fail. Then invoke something which works.
Linux.Unix.Mod has this. Dlsym( libc, "clock_gettime", ADDRESSOF(clock_gettime) ); ... clock_gettime- : PROCEDURE {C} (clk_id: INTEGER; tp: ADDRESS): INTEGER;
Ideas?
Thanks, ... P.L.
-- Dr. Felix Friedrich, Senior Scientist, Study Coordinator D-INFK Department of Computer Science ETH Zurich, CAB H 33.3 Universitätsstr. 6 8092 Zurich, Switzerland tel.: +41 44 632 8312
participants (3)
-
Felix Friedrich -
Michael Schierl -
peter＠easthope.ca