[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glibc-2.3.x: SIGRTMIN & kern_has_rtsigs() *WITHOUT* -lpthread



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



Reply to: