[Insight-developers] Problem with 3.14 release

Fri May 29 22:09:14 EDT 2009

Hello Tom,

Disabling VNL_CONFIG_ENABLE_SSE2_ROUNDING seems to fix the build  
errors, (still waiting for tests).

Making it a clean build was one of the first things I did.

I believe the experimental victoria build was build with xcode 3.1's  
gcc 4.2. I just rebuild it on my laptop with XCode 3.0's gcc 4.0, and  
the same things happened.

I have mini0 on the dashboard which just builds a ppc version on an  
intel processor and that seems to be working fine. It's a little  
complicated to get this configuration, but it's what I always use to  
install, so that I have one library for what ever I may be building.  
This is a very useful configuration, though.

mini1 should resubmit a clean build tomorrow, which will hopefully  
have the information you need from a vxl clean configure.

Ideally I would think that VNL_CONFIG_ENABLE_SSE2_ROUNDING ( and  
VNL_CONFIG_ENABLE_SSE2 ) would be enabled for the intel build, but not  
for the ppc. However looking at the way this is defined in  
vnl_config.h.in, I don't think with one configuration with one  
generated vn_config.h this is possible, because it's based on a single  
cmake variable for both architectures.

I am not sure about how the try_compile works with universal builds...

Brad

On May 29, 2009, at 6:51 PM, Tom Vercauteren wrote:

> Hi Brad,
>
> I remember testing your scenario (universal binary on intel mac) and
> it worked, weird... The configuration might have been somewhat
> different. I'll have a chance to retest on Tuesday but not before
> that.
>
> Anyhow, the errors you get are sse2 related. They typically appear
> with gcc when -msse2 is required to enable sse2 support. To bypass the
> sse2 implementation, can you try by manually disabling
> VNL_CONFIG_ENABLE_SSE2_ROUNDING in cmake? The implementation should
> then fallback to a gcc assembly when compiling for intel and to a
> vanilla c implementation when compiling fro ppc/ppc64. Then you
> shouldn't get these errors anymore (let's hope you don't get other).
>
> ITK_USE_PORTABLE_ROUND should have no effect on your build issues.
>
> The potential explanation you mention sounds realistic. It might well
> be that sse2 is supported (without any flag?) on your machine when you
> build for intel but not when you build for ppc and that the vnl test
> build only checks one of these configurations. I am not sufficiently
> familiar with universal binaries and cmake to tell but I will have a
> look at it.
>
> To ease the testing when I get back, can you provide some more
> information about your setup? I guess that your failing build is this
> one:
> http://www.cdash.org/CDash/buildSummary.php?buildid=343521
> From the system information
> http://www.cdash.org/CDash/testDetails.php?test=24107090&build=343521
> I cannot tell which version of gcc you were using. Is it the default
> one from apple?
>
> Also was it a clean build or did you reuse an old one?
>
> Tom
>
> On Fri, May 29, 2009 at 22:44, Bradley Lowekamp <blowekamp at mail.nih.gov 
> > wrote:
>> Unless RougeResearch5 is an intel, I don't see any machines on the  
>> dash
>> board which cover this case. I should have chosen by build  
>> configurations
>> for the mini's better.
>> By setting:
>>
>> CMAKE_OSX_ARCHITECTURES:STRING=ppc;i386;ppc64;x86_64
>>
>> I am getting the following compilation error:
>> [ 24%] Building CXX object
>> Utilities/vxl/core/vnl/CMakeFiles/itkvnl.dir/vnl_math.o
>> In file included from
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.cxx:8:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:51:46:
>> error: emmintrin.h: No such file or directory
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h: In
>> function ‘int vnl_math_rnd_halfinttoeven(float)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:193:
>> error: ‘_mm_set_ss’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:193:
>> error: ‘_mm_cvtss_si32’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h: In
>> function ‘int vnl_math_rnd_halfinttoeven(double)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:200:
>> error: ‘_mm_set_sd’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:200:
>> error: ‘_mm_cvtsd_si32’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h: In
>> function ‘int vnl_math_floor(float)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:359:
>> error: ‘_mm_set_ss’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:359:
>> error: ‘_mm_cvtss_si32’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h: In
>> function ‘int vnl_math_floor(double)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:366:
>> error: ‘_mm_set_sd’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:366:
>> error: ‘_mm_cvtsd_si32’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h: In
>> function ‘int vnl_math_ceil(float)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:444:
>> error: ‘_mm_set_ss’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:444:
>> error: ‘_mm_cvtss_si32’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h: In
>> function ‘int vnl_math_ceil(double)’:
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:451:
>> error: ‘_mm_set_sd’ was not declared in this scope
>> /nfs/mead/Users/blowek1/src/Insight/Utilities/vxl/core/vnl/ 
>> vnl_math.h:451:
>> error: ‘_mm_cvtsd_si32’ was not declared in this scope
>> make[2]: *** [Utilities/vxl/core/vnl/CMakeFiles/itkvnl.dir/ 
>> vnl_math.o] Error
>> 1
>>
>> If I am just building ppc, or intel, it fine (this is what I think is
>> covered on the dash board. But if it's both architectures, I get  
>> these error
>> messages.
>> As intel and ppc have different endianness, a similar handling of  
>> this cross
>> compilation issue was done here in itkConfigure.h.in :
>> /* what byte order */
>> /* All compilers that support Mac OS X define either __BIG_ENDIAN__  
>> or
>>    __LITTLE_ENDIAN__ to match the endianness of the architecture  
>> being
>>    compiled for. This is not necessarily the same as the  
>> architecture of
>>    the machine doing the building. In order to support Universal  
>> Binaries on
>>    Mac OS X, we prefer those defines to decide the endianness.
>>    On other platform, we use the result of the TRY_RUN. */
>> #if !defined(__APPLE__)
>>   #cmakedefine CMAKE_WORDS_BIGENDIAN
>>   #ifdef CMAKE_WORDS_BIGENDIAN
>>     #define ITK_WORDS_BIGENDIAN
>>   #endif
>> #elif defined(__BIG_ENDIAN__)
>>   #define CMAKE_WORDS_BIGENDIAN
>>   #define ITK_WORDS_BIGENDIAN
>> #endif
>> I think the checks for VNL_CONFIG_ENABLE_SSE2_ROUNDING, appear to  
>> build a
>> build test only. This is insufficient when building an apple  
>> universal
>> binary.
>> Brad
>>
>>
>> On May 29, 2009, at 4:11 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C]  
>> wrote:
>>
>> Hello,
>> I think there is a problem with the 3.14. If you have an intel mac  
>> and are
>> building a universal binary there is a compilation issue.
>> This is likely due to the rounding changing, and how it checks for  
>> the
>> architecture. I am building an experimental now (victoria.nlm). And  
>> I am
>> going to change mini1.nlm, to cover this case tonight too.
>> Brad
>> ========================================================
>> Bradley Lowekamp
>> Lockheed Martin Contractor for
>> Office of High Performance Computing and Communications
>> National Library of Medicine
>> blowekamp at mail.nih.gov
>>
>> <ATT00001.txt>
>>
>> ========================================================
>>
>> Bradley Lowekamp
>>
>> Lockheed Martin Contractor for
>>
>> Office of High Performance Computing and Communications
>>
>> National Library of Medicine
>>
>> blowekamp at mail.nih.gov
>>
>>