On 06/05/11 02:53, Kurt Roeckx wrote:
It failed on hurd with this message: i486-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. ..... In file included from ag.c:35:0: fmemopen.c: In function 'ag_fmemioctl': fmemopen.c:752:10: error: '_IOT__IOTBASE_fmemc_get_buf_addr_t' undeclared
I've done some more digging. Hurd presumes that it can make requirements on the arguments to the _IOWR() macro. This flys in the face of decades of UNIX history. glibc documents this weirdo-ness in an obscure header:
/* Standard flavors of ioctls. _IOT_foobar is defined either in this file, or where struct foobar is defined. */ [...] #define _IOWR(g, n, t) _IOC (IOC_INOUT, (g), (n), _IOC_ENCODE_TYPE (t)) /* These macros do some preprocessor gymnastics to turn a TYPESPEC of `struct foobar' into the identifier `_IOT_foobar', which is generally defined using `_IOT' (above) in whatever file defines `struct foobar'. For a TYPESPEC that does not begin with `struct' produces a different identifier: `int' produces `_IOT__IOTBASE_int'. These identifiers are defined for the basic C types above. */ #define _IOC_ENCODE_TYPE(typespec) _IOC_ENCODE_TYPE_1(_IOTBASE_##typespec) #define _IOTBASE_struct #define _IOC_ENCODE_TYPE_1(typespec) _IOC_ENCODE_TYPE_2(typespec) #define _IOC_ENCODE_TYPE_2(typespec) _IOT_##typespec
glibc for Hurd is wrong. Hurd should use alternate macros for creating ioctl id numbers (_IOWRT ?). I doubt Mr. Glibc would agree, however. The next release will be fixed for Hurd with: #ifdef HURD #define _IOT__IOTBASE_fmemc_get_buf_addr_t sizeof(fmemc_get_buf_addr_t) #endif I don't particularly want to keep the fmemopen.c file out of sync with my private library. Elsewhere, I *do* use the fake ioctl. *sigh*. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
