Re: [Discuss-gnuradio] cmake build

[Josh Blum]

On 09/11/2011 04:37 AM, Michael Dickens wrote:
> Unless Josh changed something recently, the cmake build (with volk
> disabled) worked for me under 10.6.8, XCode 3.2.3, 64-bit.  It looks
> like Ben is doing this testing on 10.5.8, XCode 3.1.4 -- which by
> default will use 32-bit for either PPC or Intel compiling, and,
> really, getting 64-bit was somewhat of a challenge until 10.6.  A
> "fat" or "universal" build o 10.5 meant 32-bit PPC and Intel merged
> into a single file.  IIRC, gcc under 10.5.8 could be coerced into
> doing 64-bit, but doing so was much more reliable using Apple's
> interface.  All of that changed with 10.6, since 64-bit was the
> default for any capable processor (and, all processors were Intel,
> and mostly legacy ones were 32-bit only), and "universal" meant (and
> still means) both 32- and 64-bit Intel compiling (merged).  Given
> that "we" designed the GR autotools build to work on OSX with both
> 32- and 64-bit compiling, starting early in 10.5 days, I'm glad that
> that build still works correctly.
> 
> With the above I mind, it would probably help to know from Ben what
> "arch" and "uname -a" return. Looking at Josh's pastebin change, I
> would bet that CMAKE_SYSTEM_PROCESSOR is "i386" (it is for all Intel
> OSX builds, as far as I know).  But, under 10.5,
> CMAKE_SYSTEM_PROCESSOR should probably be "i386", not "x86_64" --
> but, it really depends on what Ben's system is / provides. - MLD
> 
> 

This is only an issue w/ gr-filter where we try to perform arch
detection. The way volk is doing it should always be ok :-)

I made a branch detect_x86_type on jblum.git, where I try to detect the
compiler's bit width in filter. I think its a lot more robust:

http://gnuradio.org/cgit/jblum.git/log/?h=detect_x86_type

-josh