|Subject:||Re: [Discuss-gnuradio] MacPorts and GNU Radio 32-bit|
|Date:||Thu, 11 Feb 2010 08:15:45 -0500|
gcc -v machine uname -aOnce I figure out the logic (and, via the below discussion, I think I know what to do but I just want more info to confirm my beliefs), I can insert a warning or something into the portfile for wxgui so that this issue doesn't happen. - MLD
I think this is an OSX 10.6 32/64 bit issue, which I've worked around in GNU Radio already -- and as folks are finding, this error occurs in a background requirement (wxPython). IIRC:
* If you boot into 10.5 (which is mixed 32/64-bit, no matter the CPU), you get 32-bit compiling by default with the option of 64-bit via the '-arch x86_64' flag to the compiler. This behavior made sense because the kernel itself wasn't truly 64-bit.
* If you boot into 10.6 via the 32-bit kernel, then you get 32-bit compiling by default even if your CPU supports 64-bit compiling (just like 10.5, btw).
* If you boot into 10.6 via the 64-bit kernel (assuming your CPU supports it; not all do that can execute 10.6), then you get 64-bit compiling by default.
* A simple way to check to see which bit-size compiling is currently supported is to get "sizeof (void*)" and see if it is 4 or 8 (32 or 64 bit, respectively). Note that performing the test in this manner means one cannot make a "universal" executable via combining "-arch i386" and "-arch x86_64" ... you have to choose one way or the other. I've already implemented that change into the GNU Radio portfiles: when doing a universal install each file is compiled twice then the results merged together.
* wxPython (188.8.131.52 -- the latest stable release) will currently compile only as 32-bit; the error folks are getting occurs when trying to compile wxPython as 64-bit.
|[Prev in Thread]||Current Thread||[Next in Thread]|