At Mon, 21 Oct 2002 03:44:42 -0700, Chris Wedgwood wrote: > I'm not *who* is at fault here (quite possibly me), but Debian 'sid' > now uses glibc-2.3.x instead of glibc-2.2.x. > > Bug: SIGRTMIN/__libc__current_sigrtmin() under glibc-2.2.x and > glibc-2.3.x work differently. > > Under glibc-2.2.x you can build an application and *NOT* link with > -lpthread and have SIGRTMIN (ie. __libc__current_sigrtmin() return > sane value), under glibc-2.3.x you cannot do this. For glibc-2.3.x > you must use -lpthread which over-rides kernel_has_rtsigs().
__libc_current_sigrtmin, kernel_has_rtsig? > This means any any applications using glibc-2.3.x which are not > compiled -lpthread may crash as they will get SIGIO unexpectedly in > places... and that's not very cool. > > I checked the source and don't actually see why this works in 2.2.x > and not 2.3.x; the code involved hasn't changed, but maybe when > linking with 2.2.x I get a different kernel_has_rtsigs() andhow? Could you take us the test case which you get trouble with? > P.S. Is there a defined glibc API for allocation and management of > realtime signals? I don't see one which means using them from > libraries and simialr is not an option. 'info libc' Regards, -- gotom
