Bug#91311: semid_ds conflicts with SUSv2
At Wed, 12 Mar 2003 13:53:23 +0000,
Mark Brown wrote:
>
> On Wed, Mar 12, 2003 at 10:09:08PM +0900, GOTO Masanori wrote:
>
> > So, what is the problem? TenDRA warns something? I rebuild TenDRA
> > without any your debian patches, but the result of my build is not
> > related any semid_ds issue.
>
> TenDRA fails to compile when one of the patches is removed since it
> checks the exact type while building its APIs. IIRC it's one of the
> bits in this hunk but I can't remember which:
>
> --- tendra-4.1.2.orig/src/lib/machines/linux/80x86/startup/xpg3.h
> +++ tendra-4.1.2/src/lib/machines/linux/80x86/startup/xpg3.h
> @@ -4,8 +4,9 @@
> #define _SVID_SOURCE 1
> #define _BSD_SOURCE 1
> #define __SVR4_I386_ABI_L1__ 1
> -#define __semun_defined 1
>
> #define __WRONG_XPG3_SEARCH_H
> #define __WRONG_XPG3_SEARCH_H_SRCH_OLD
> #define __WRONG_XPG3_SEARCH_H_SRCH_PROTO
> +#define __WRONG_XPG3_SYS_SEM_H
> +#define __WRONG_XPG3_SYS_SEM_H_SEM_PROTO
>
> One of the last two defines there. I can check further tonight if you
> want.
Yes, please check. My build does not barf the error in sem.[ch] and
sem_prot.[ch].
> > Repeatedly, some architecture defined it as unsigned long.
> > sizeof(unsigned long) > sizeof(unsigned short).
> > If we change it to unsigned short, then the data may be lost.
>
> Sorry, I don't know the best way to fix this in a glibc-style fashion.
> It's a rather pedantic bug at the best of times so making a fix only
> come into play when people particularly ask for standards conformance
> might be an option.
OK, I see the point is "pedantic" conformance analysis of glibc
definition, not standard conformance.
Regards,
-- gotom
Reply to: