On 2011-07-11 Bruce Korb <bk...@gnu.org> wrote: > On 07/11/11 10:14, Kurt Roeckx wrote: >>>>>> That means that hurd has a non-standard definition for _IOWR.
>>>>> #ifdef HURD >>>>> #define _IOT__IOTBASE_fmemc_get_buf_addr_t sizeof(fmemc_get_buf_addr_t) >>>>> #endif >>>> 5.12 still failed with the same error message. >>> Then "HURD" is not #defined in hurd. I had to read glibc/gcc source code >>> to tease out that name, but I guess I read wrong. What _is_ the >>> #define that says the compile is for hurd? On other platforms, the _IOWR >>> macro just works. HURD itself is broken. >> I've been told it's __GNU__ > I would surely hope not. The reason being is that there is this > campaign on to get everyone to use GNU/Linux as the name of the > platform commonly referred to as "Linux". If __GNU__ were used to > mean "GNU/Hurd", then it would severely muddy the waters about what > is meant by GNU. So, please tell me the marker is __hurd__ (or some > variation) and not __GNU__. It would be _so_ wrong..... [...] Hello Bruce, According to http://www.gnu.org/software/hurd/hurd/porting/guidelines.html __GNU__ is the correct macro: | If you need to include specific code for GNU/Hurd using #if ... | #endif, then you can use the __GNU__ symbol to do so. However comparing gcc -dM -E - < /dev/null | sort -u " on GNU/Hurd and Linux it looks like __gnu_hurd__ is also defined. You could use this macro instead of __GNU__ if you prefer to. cu andreas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
