Seems a lot of assumptions are made about the widths of certain types that make many usages of the library throw errors when building for 32-bit. For example, nextEventMatchingMask_untilDate_inMode_dequeue_'s mask parameter takes an NSInteger (https://github.com/servo/cocoa-rs/blob/bce77bf83b10dd6ec54bb8ce897baeb5f5b24d46/src/appkit.rs#L312), but the bitflags that are meant to be used there are backed by a libc::c_ulonglong, which is not compatible in 32-bit builds.
Seems a lot of assumptions are made about the widths of certain types that make many usages of the library throw errors when building for 32-bit. For example,
nextEventMatchingMask_untilDate_inMode_dequeue_
'smask
parameter takes anNSInteger
(https://github.com/servo/cocoa-rs/blob/bce77bf83b10dd6ec54bb8ce897baeb5f5b24d46/src/appkit.rs#L312), but the bitflags that are meant to be used there are backed by alibc::c_ulonglong
, which is not compatible in 32-bit builds.This causes, for example, https://github.com/tomaka/glutin to fail to compile under 32-bit https://github.com/tomaka/glutin/issues/803 at least, and there may be more errors lurking around in there that this causes.