* Orion Poplawski: > It seems that numpy is defining a uint32_t type as long unsigned int > on i686, while glibc(?) is defining it as unsigned int. Now what > puzzles me a little is that on i686 aren't these both 4-byte integers > and no not incompatible at all? The types int and long are distinct according to C rules. The problem seems to be in h5py/api_types_ext.pxd: from numpy cimport int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t I think it should use the types from <stdint.h> instead, at least in the global scope. For certain Numpy functions, it may be required to reference them as numpy.uint32_t etc. Thanks, Florian -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
