Re: lib/60215: ld.elf_so dlerror() state is not thread-local

["Izumi Tsutsui via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR lib/60215; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: lib/60215: ld.elf_so dlerror() state is not thread-local
Date: Thu, 30 Apr 2026 06:02:23 +0900

 > >   > ld.elf_so doesn't itself have any notion of threads, which makes it
 > >   > quite hard to make error messages thread-safe.
 > >   
 > >   >From the application's point of view, this is not only about making
 > >   error messages thread-safe.  If dlerror() state is process-global,
 > >   the usual dlerror()/dlsym()/dlerror() sequence can report an
 > >   unrelated error from another LWP and make the application take
 > >   the wrong error path.
 > 
 > Yes, it is possible to return unrelated errors, but for any sane 
 > application it shouldn't result in a different error path. That would 
 > mean that the application is branching based on dlerror() and not the 
 > actual error status of the failing function.
 
 I'd like to make sure I understand your point (i.e. the definitions
 of "sane" and "actual error status") correctly.
 
 As I understand it, your point is:
 
  - POSIX specifies dlsym(3) shall return a null pointer if the symbol
    cannot be found
 
  - POSIX also specifies more detailed diagnostic information shall be
    available through dlerror(3)
     https://pubs.opengroup.org/onlinepubs/9799919799/functions/dlsym.html
     
  - Therefore, on NetBSD, if dlsym(3) returns a non-NULL pointer,
    GLib/GObject-Introspection should not treat the lookup as failed
    only because dlerror(3) has a non-NULL value
 
 If that understanding is correct, the immediate ruby/gtk3 failure
 appears to be on the GLib/GObject-Introspection side.  It treats
 the `gtk_events_pending` lookup as failed even though dlsym(3)
 returned a valid non-NULL function pointer.
 
 Linux dlsym(3) man page claims dlsym() can return NULL without error:
  https://man7.org/linux/man-pages/man3/dlsym.3.html
 Maybe this is the reason why GLib/GObject-Introspection always
 checks dlerror().
 
 I will look at a pkgsrc-side workaround in that direction.
 
 One remaining point is documentation on NetBSD side.
 POSIX specifies that it is *implementation-defined*
 whether or not dlerror() is thread-safe:
  https://pubs.opengroup.org/onlinepubs/9799919799/functions/dlerror.html
 
 If NetBSD's dlerror() state is intentionally process-global,
 I think dlfcn(3) should document that behavior explicitly.
 The current man page does not appear to say whether dlerror(3)
 state is thread-local or process-global in multi-threaded programs:
  https://man.netbsd.org/dlfcn.3
 
 ---
 Izumi Tsutsui