[Insight-users] help building ITK with WrapITK

Wed Aug 19 07:05:51 EDT 2009

Hi.
As promised in my previous mail, I do indeed have a help request
involving WrapITK.  
So far it is just about building ITK with the correct options enabled. I
get a Python error previously I just did not build with the Python
option so I have not encountered this.

Some googleing reveals that this is a long-standing 'feature' of python
...

So how do other people manage to build it? 

Somehow the build process gets to swigrunPython.cxx without the cpp
macro SIZEOF_LONG being defined, it seems. 

There may be a second issue here, why does the value which appears to be
defined in the CMakeCache (below) not get  passed along to the building
of this part.

The test at line 679 of pyport.h then fails, as the test of whether
SIZEOF_LONG is defined is never done.
Thanks in advance,
Robert

More info below:

A little test program of mine reveals that the actual required constant
LONG_BIT is correct for this platform, in contrast to what the build
message says.
build64]$ ./longbit
LONG_BIT = 64
SIZOF_LONG = 0  
LONG_MAX = 9223372036854775807

Platform is RedHat EL5 with locally installed Python2.6.2 
g++ --version says: g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)

ITK is from CVS as is cableSwig. (Yesteday)

Last output of make:

82 [ 74%] Building CXX object
Wrapping/CSwig/SwigRuntime/CMakeFiles/SwigRuntimePython.dir/swigrunPytho
n.o
 83 In file included from
/dls_sw/apps/python/2.6.2/include/python2.6/Python.h:58,
 84                  from
/home/kny48981/sources/ITK_cvs/build64/Wrapping/CSwig/SwigRuntime/swigru
nPython.cxx:30:
 85 /dls_sw/apps/python/2.6.2/include/python2.6/pyport.h:685:2: error:
#error "LONG_BIT definition appears wrong for platform (bad gcc/glibc
config?)."
 86 make[2]: ***
[Wrapping/CSwig/SwigRuntime/CMakeFiles/SwigRuntimePython.dir/swigrunPyth
on.o] Error 1
 87 make[1]: ***
[Wrapping/CSwig/SwigRuntime/CMakeFiles/SwigRuntimePython.dir/all] Error
2
 88 make: *** [all] Error 2

This information can be fount in CMakeCache.txt:

1268 //Result of CHECK_TYPE_SIZE
1269 CMAKE_SIZEOF_LONG:INTERNAL=8

/dls_sw/apps/python/2.6.2/include/python2.6/pyport.h

This appears to be a bug in python. In the above file, at lines 655-686,
a series of macros is tested, however the case in which LONG_MAX is
defined but SIZEOF_LONG is not actually defined is not covered. This
appears to be the case on this platform and the 'error' test fails, even
though LONG_BIT is defined correctly (because SIZEOF_LONG appears not to
be defined)

The python developers appear to disagree and say it's a bug in the
compiler, though it is  obvious to me that this test at line 679 should
not be reached if either of the operands of the test are not defined, it
exits on error when in fact the condition it is supposed to be testing
(whether a 'long' is 32 or 64 bits) is correct. So at the very least,
the wrong error message is produced. If SIZEOF_LONG is required to be
present this should be tested first. But I mustn't argue about that here
, though I feel that 'deaf ears' will be the outcome of going to the
python list based on my reading of the historical entries about this
issue there.

655 /* limits.h constants that may be missing */
656
657 #ifndef INT_MAX
658 #define INT_MAX 2147483647
659 #endif
660
661 #ifndef LONG_MAX
662 #if SIZEOF_LONG == 4
663 #define LONG_MAX 0X7FFFFFFFL
664 #elif SIZEOF_LONG == 8
665 #define LONG_MAX 0X7FFFFFFFFFFFFFFFL
666 #else
667 #error "could not set LONG_MAX in pyport.h"
668 #endif
669 #endif
670
671 #ifndef LONG_MIN
672 #define LONG_MIN (-LONG_MAX-1)
673 #endif
674
675 #ifndef LONG_BIT
676 #define LONG_BIT (8 * SIZEOF_LONG)
677 #endif
678
679 #if LONG_BIT != 8 * SIZEOF_LONG   //<<<<<<<<<<<<******* THIS IS
REACHED EVEN IF THE MACRO IS UNDEFINED!!!!
680 /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some
recent
681  * 32-bit platforms using gcc.  We try to catch that here at
compile-time
682  * rather than waiting for integer multiplication to trigger bogus
683  * overflows.
684  */
685 #error "LONG_BIT definition appears wrong for platform (bad
gcc/glibc config?)."
686 #endif
687

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.

Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 

Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.

Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090819/fe6719c4/attachment-0001.htm>