Hello, Peter B, le mer. 27 juil. 2022 18:02:53 +0100, a ecrit: > Regarding > "/../sysdeps/mach/hurd/htl/pt-mutex-lock.c: No such file or directory/" > Does this suggest a missing dependency?
No it's just that you don't have the glibc source code in your current directory :) > #11 0x010bcff2 in __GI___assert_fail (assertion=0x10538b5 "self != NULL", > file=0x10538ab "pt-self.c", line=28, function=0x10538c4 > <__PRETTY_FUNCTION__.1> "__pthread_self") at assert.c:101 > #12 0x0104d33f in __pthread_self () at pt-self.c:28 > #13 __pthread_self () at pt-self.c:25 > #14 0x0803d0c7 in lock () at sem_inc.c:145 > #15 0x0803d1d6 in DUMA_get_sem () at sem_inc.c:230 > #16 0x0803afcc in _duma_init () at duma.c:1034 > #17 0x0803c386 in _duma_malloc (size=716, filename=0x803e060 <unknown_file> > "UNKNOWN (use #include \"duma.h\")", lineno=0) at duma.c:1966 > #18 0x0803cc8b in malloc (size=716) at duma.c:2424 > #19 0x0104c33d in __pthread_alloc (pthread=0x1039d30) at pt-alloc.c:124 > #20 0x0104c773 in __pthread_create_internal (thread=0x1039d78, > attr=0x1039d7c, start_routine=0x0, arg=0x0) at pt-create.c:120 > #21 0x0105146b in _init_routine (stack=<optimized out>) at > ../sysdeps/mach/hurd/htl/pt-sysdep.c:66 > #22 0x0001164b in call_init (l=<optimized out>, argc=argc@entry=1, > argv=argv@entry=0x1039e54, env=0x1039e5c) at dl-init.c:74 > #23 0x000117f5 in call_init (env=0x1039e5c, argv=0x1039e54, argc=1, > l=<optimized out>) at dl-init.c:37 > #24 _dl_init (main_map=0x389d0, argc=1, argv=0x1039e54, env=0x1039e5c) at > dl-init.c:88 > #25 0x00002052 in _dl_start_user () from /lib/ld.so Ok, that confirms what I was guessing: libpthread is initializing itself, and for that uses a dynamic allocation, during which duma calls pthread_self, which cannot work yet. Ideally libpthread would not need to allocate anything for its initialization, but that's really tricky. Possibly we can trick pthread_self into being callable very early. (this is probably working on Linux only by luck) Samuel
