hanks for all the feedback thus far! Can those of you on this thread
return back to me the following (as executed in a terminal,
individually):
gcc -v
machine
uname -a
Once 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 (2.8.9.10 -- 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.
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
