Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#21292 closed defect (fixed)

gnuradio-core does not compile on snow leopard

Reported by: banister@… Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 1.8.99
Keywords: Cc: mf2k (Frank Schima), michaelld (Michael Dickens)
Port: gnuradio-core

Description (last modified by mf2k (Frank Schima))

Snow leopard, using Xcode 3.2 sudo port install gnuradio produces the following during the build of gnuradio-core.

float_dotprod_3dnow.S:63:suffix or operands invalid for `push'
float_dotprod_3dnow.S:67:suffix or operands invalid for `pop'
float_dotprod_sse.S:63:suffix or operands invalid for `push'
float_dotprod_sse.S:163:suffix or operands invalid for `pop'

These files appear to be the 32-bit versions as there are also files named float_dotprod_3dnow64.S and float_dotprod_sse64.S. Looking at the generated Makefiles, it appeared to select a sub-architecture of i386 rather than x86_64.

Change History (10)

comment:1 Changed 15 years ago by mf2k (Frank Schima)

Description: modified (diff)

comment:2 Changed 15 years ago by banister@…

Appears to be a problem with configure mis-detecting the 64-bit system. Adding --with-md-cpu=x86_64 to the configure line allows this port to compile. Other of the gnuradio pieces have similar issues. Gnuradio ultimately depends on libsdl which is not available yet.

comment:3 Changed 15 years ago by mf2k (Frank Schima)

Cc: macsforever2000@… added

Cc Me!

comment:4 Changed 14 years ago by michaelld (Michael Dickens)

Cc: mlk@… added

Cc Me!

comment:5 Changed 14 years ago by michaelld (Michael Dickens)

I think the issue is actually that GNU libtool doesn't yet correctly guess (via config.guess) darwin 10's host / build / target info.

I have integrated a temporary fix for this issue in the latest GNU Radio GIT master, along with other 64-bit pointer fixes in both of the Darwin-specific modules: gr-audio-osx and usrp/host/lib/*darwin* . I will update the GNU Radio Portfiles in the next number release (3.2.3 or 3.3; I think the latter), which will provide 10.6 / 32- and 64-bit compatibility for those Ports for which the background Ports are also 32- or 64-bit.

The fix specified (--with-md-cpu...) will work for those components that will compile under a 64-bit CPU. Note that if your computer's CPU is 32-bit, then you don't need this configure flag (and, further, it probably won't work).

I'm also bumping the GNU Radio ports to 3.2.2, along with the necessary fixes therein for changes in port names. See ticket:22260 .

comment:6 Changed 14 years ago by michaelld (Michael Dickens)

Owner: changed from macports-tickets@… to michaelld@…
Status: newassigned

I'll regenerate the changes to the GNU Radio GIT master from a few months ago & update the portfiles to handle 64-bit compilation as well as deal better with 10.6. Give me a few days to sort these out & verify.

comment:7 Changed 14 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: assignedclosed

I've checked in changes in r63573 and r63574 that work for me on 10.5 i386 and universal and 10.6 x86_64 (but not gnuradio-wxgui because it requires py2X-wxPython which requires wxWidgets 2.8.X which isn't 64-bit). I haven't tried executing the PPC code in 10.5 since I don't have a PPC-Mac. Nor have I tried compiling or executing as 32-bit in 10.6 since that GNU Radio still compiles cleanly as 32-bit on 10.5 (and, did before under 10.6). I'm closing this ticket for now; please check out these changes and if they don't work then either reopen the ticket or make a new one.

comment:8 Changed 14 years ago by alex@…

I've submitted a workaround patch to py26-wxpython:

https://trac.macports.org/ticket/19583

This solves the problem with wxWidgets, py26-wxpython builds fine after that.

I'm now running into a different issue that configure doesn't find that package - gr_wxgui_INCLUDES is empty:

gr_wxgui_INCLUDES=

It seems that configure tries to determine the include path using pkg-config

gr_wxgui_INCLUDES=$PKG_CONFIG --cflags-only-I ${pc_comp_name}

but pkg-config returns nothing for py26-wxpython on my system tho it's installed:

$ pkg-config --cflags-only-I py26-wxpython Package py26-wxpython was not found in the pkg-config search path. Perhaps you should add the directory containing `py26-wxpython.pc' to the PKG_CONFIG_PATH environment variable No package 'py26-wxpython' found

However, it's correctly installed and activated:

bash-3.2$ port activate py26-wxpython ---> Activating py26-wxpython Error: port activate failed: Image error: py26-wxpython @2.8.9.1_0 is already active.

I now build the port with a pkg target and see if that helps. However, I think this needs to be fixed... you cannot rely on ports being installed as pkg...

comment:9 Changed 14 years ago by alex@…

pkg target and installing the pkg for py26-wxpython doesn't help either...

comment:10 Changed 14 years ago by michaelld (Michael Dickens)

Thanks for notifying me about the updated ticket on wxpython. I think that the current portfiles find the PKG_CONFIG installed items correctly on 10.5 and 10.6 (for those that can be installed on the latter), and everything (that can) installs correctly on all variants of 10.5 and 10.6 -- hence, this ticket is fixed.

As I haven't tried your patch for wxpython, I can only believe that the .pc file for wxpython isn't installed as expected by GNU Radio if the info is not found, or something is missing from what GNU Radio expects (e.g., as found in the log file). That said, I'll wait until the wxpython ports are updated before changing these ports since, at least in my experience, they're not broken right now (excepting the known issue of wxpython not compiling as 64-bit on 10.6, which isn't GNU Radio's issue). Once wxpython is updated, if it's still clear that PKG_CONFIG isn't finding the installed .pc file, then please open a new ticket since I think this one has been fixed as well as it can be under the circumstances.

Note: See TracTickets for help on using tickets.