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
