On 07/06/2012 11:21 PM, Pascal Manchon wrote:
To follow your request, I just did 2 tries on compiling libdivecomputer on my native OSX 64bit environment :
First try without options (compiles for 64bit) :
$ ./configureSecond try with :
$ export CPPFLAGS=-m32 $ export LDFLAGS=-m32 $ ./configure --build=i686and this seem indeed to work correctly (at least the computer starts dumping its memory)
That's exactly what I suspected. On most 32bit unix systems long is 32bit, just like int. But on 64bit, long is 64bit, but int is 32bits. Thus on 32bit int and long are the same, but not on 64bit.
What actually made me try the unsigned long type is the man page for ioctl : https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManP...
I was a little to quick when looking up info. The page I referred to, documents the data type of the third ioctl parameter, not the second "request" parameter. The page you refer to clearly documents request being "unsigned long". Strange is that on my linux system the manpages says its "int", but the <sys/ioctl.h> has a prototype with "unsigned long int". Thus unsigned long should work fine for both. Might be a bug in the linux manpages.
I'm not seeing any problems on 64bit linux, but maybe the actual value fits into an int, and on macosx it does not? Can someone check the actual values for TIOCMBIC and TIOCMBIS on 32 and 64bit macosx (using unsigned long of course).
Found a detailed analysis of the problem here:
http://bugs.python.org/issue1471
Jef