pointers in OSX 10.5 are 64bits - cpl_multiproc:CPLGetPID() uses int

[kyngchaos]

When compiling on OSX 10.5, I get an error in cpl_multiproc:

libtool: compile:  /Users/kyngchaos/bin/c++ub_64 -Wall -Os -DOGR_ENABLED -I/Users/Shared/src/gdal/svn/gdal/port \
-I/Library/Frameworks/UnixImageIO.framework/unix -I/Users/Shared/unix/geotiff/include \
-I/Users/Shared/unix/netcdf -I/Users/Shared/unix/netcdf/include -I/Users/Shared/unix/cfitsio \
-I/Users/Shared/unix/cfitsio/include -DHAVE_CURL -c cpl_multiproc.cpp  -fno-common -DPIC \
-o .libs/cpl_multiproc.o
cpl_multiproc.cpp: In function 'int CPLGetPID()':
cpl_multiproc.cpp:867: error: cast from '_opaque_pthread_t*' to 'int' loses precision

Changing CPLGetPID to long works - long in OSX 10.5 is 64bits for x86_64 and ppc64 architectures and 32bits for i386 and ppc archs. But this may not be the proper way to fix this, as I don't know how it would affect other platforms.

Note: OSX 10.5 builds 32bit by default, even on 64bit processor systems, but can build 64bit with a simple -arch CFLAG.

[warmerdam]

Lets deal with this now.

[kyngchaos]

It looks like the only changes needed are in the pthread section of cpl_multiproc.cpp and cpl_multiproc.h. It's only ever used to print debug info and the printf functions seem to be handling it fine.

Maybe, since this is for pthreads, pthread_t should be used instead of long? I can try this when I build the 1.5b1 source.

[warmerdam]

William,

The CPLGetPID() is accessable to the application and can be used for a variety of purposes. In practice a scan of the code suggests it is mostly used to form filenames that are thread specific. I am going to change the return type to be GIntBig (generally a 64bit integer). This should allow embedding values that are really pointers on systems where this is necessary, and should not cause to much disruption to applications.

[warmerdam]

Note, we can't use types like pthread_t in the public API since we don't want it to depend on pthreads.

I have updated things to use GIntBig as the PID type in trunk (r13253).

Please reopen if this doesn't fix the build problem.