On Tue, May 11, 2010 at 12:12:55AM +0400, Sergey Vlasov wrote:
> On Mon, May 10, 2010 at 10:59:00PM +0400, Sergey Bolshakov wrote:
> > rt_sigprocmask(SIG_SETMASK, ~[RT_1 RT_2 RT_3 RT_4 RT_5 RT_6 RT_7 RT_8 RT_9 RT_10 RT_11 RT_12 RT_13 RT_14 RT_15 RT_16 RT_17 RT_18 RT_19 RT_20 RT_21 RT_22 RT_23 RT_24 RT_25 RT_26 RT_27 RT_28 RT_29 RT_30 RT_31], 0x80580ac, 4) = -1 EINVAL (Invalid argument)
> Ага, значит, не работает только на i386.
> 
> В klibc 1.5.17 есть commit 3cd286a4bff43ea339d2a815047703d134c0ecfc:
> 
>     [klibc] Use x86_32 cleaned up signal.h
>     
>     x86 merges cleaned the header up, do the inverse then arm:
>     nuke duplication.
> 
> -/* The in-kernel headers for i386 still have libc5
> -   crap in them.  Reconsider using <asm/signal.h>
> -   when/if it gets cleaned up; for now, duplicate
> -   the definitions here. */
> +/* The in-kernel headers for i386 got clean up, use them. */
> 
> где из usr/include/arch/i386/klibc/archsignal.h выкинуто всё, что там
> было, и вставлено #include <linux/signal.h>.  Однако в заголовках ядра
> это приводит к arch/x86/include/asm/signal.h, где внутри
> обнаруживается следующее:
> 
> #ifdef __KERNEL__
> 
> /* ... тут пригодное для нужд klibc определение sigset_t */
> 
> #else
> /* Here we must cater to libcs that poke about in kernel headers.  */
> 
> #define NSIG		32
> typedef unsigned long sigset_t;
> 
> #endif /* __KERNEL__ */
> 
> Не знаю, что имел в виду автор изменения в klibc,

Старый код в usr/include/arch/i386/klibc/archsignal.h конфликтует с
<asm/signal.h>, и автор изменения, наверное, просто выкинул то, что
мешало компиляции.

Другая версия: у нас глючный <asm/signal.h>, а у автора в этом файле
находится что-то более приличное.  По крайней мере, простое сравнение
файлов /usr/include/asm-generic/signal.h и /usr/include/asm/signal.h
наводит на такую мысль.

Я вижу 2 варианта решения: заменить в arch/i386/klibc/archsignal.h
<linux/signal.h> на <asm-generic/signal.h>, или скопировать содержимое
arch/x86_64/klibc/archsignal.h в arch/i386/klibc/archsignal.h

Какой вариант вам больше нравится?

> но результат на i386
> получился явно нерабочим - libc5 crap из заголовков ядра никуда не
> делся даже в v2.6.34-rc7.


-- 
ldv