Opened 16 years ago
Closed 16 years ago
#1963 closed defect (fixed)
pointers in OSX 10.5 are 64bits - cpl_multiproc:CPLGetPID() uses int
Reported by: | kyngchaos | Owned by: | warmerdam |
---|---|---|---|
Priority: | high | Milestone: | 1.5.0 |
Component: | default | Version: | svn-trunk |
Severity: | major | Keywords: | multiproc CPLGetPID |
Cc: |
Description
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.
Change History (4)
comment:1 by , 16 years ago
Priority: | normal → high |
---|---|
Status: | new → assigned |
comment:2 by , 16 years ago
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.
comment:3 by , 16 years ago
Keywords: | multiproc CPLGetPID added |
---|
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.
comment:4 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
Lets deal with this now.