Error in SWIG C++ when installing gnuradio +full on OSX 10.6

[michaelld (Michael Dickens)]

OS X Version: 10.6.8 Xcode: 3.2.6

Error is related to SWIG C++ files; see attachment.

[michaelld (Michael Dickens)]

First thing to try:

sudo port clean gnuradio
sudo port install gnuradio +full

if that does not work, then what does "port installed" return?

[b.forbort@…]

The same issue occurred after a clean. See attached installed.txt for the output of port installed.

I also just ran selfupdate and found all my ports are up-to-date. I'm currently running system update to insure everything else is up-to-date. If necessary, I can also format the HD and reinstall OSX.

[larryv (Lawrence Velázquez)]

Replying to b.forbort@…:

I also just ran selfupdate and found all my ports are up-to-date.

Note that our rsync mirror is not updating.

[b.forbort@…]

Replying to larryv@…:

Replying to b.forbort@…:

I also just ran selfupdate and found all my ports are up-to-date.

Note that our rsync mirror is not updating.

Here's my output from the same commands

$ date
Tue Jul  9 14:22:50 PDT 2013
$ sudo port sync
--->  Updating the ports tree
$ ls -l /opt/local/var/macports/sources/rsync.macports.org/release/tarballs
total 111112
-rw-r--r--   1 root  admin       512 Jul  5 15:03 PortIndex.rmd160
drwxr-xr-x  24 root  wheel       816 Jan 31 09:30 base
-rw-r--r--   1 root  admin   3594240 Jul  5 15:03 base.tar
-rw-r--r--   1 root  admin       512 Jul  5 15:03 base.tar.rmd160
drwxr-xr-x  51 root  wheel      1734 Jul  9 14:23 ports
-rw-r--r--   1 root  admin  53278720 Jul  5 15:03 ports.tar
-rw-r--r--   1 root  admin       512 Jul  5 15:03 ports.tar.rmd160
$ date
Tue Jul  9 14:23:30 PDT 2013

[b.forbort@…]

Fixed jack port

[b.forbort@…]

Fixed an issue with the jack port, however the build still fails around blocks_swig1PYTHON_wrap.

I'm reverting to gnuradio-3.6.5_0+full for the moment to verify that it still installs and to actually get some work done.

[michaelld (Michael Dickens)]

You can try the new gnurado-legacy port, which installs 3.6.5.1. That is, if you can get ports synced. Some of the ports listed as installed are now older, e.g., qt4-mac. You might want to do "sudo port upgrade outdated" before anything else.

[b.forbort@…]

Replying to michaelld@…:

You can try the new gnurado-legacy port, which installs 3.6.5.1. That is, if you can get ports synced. Some of the ports listed as installed are now older, e.g., qt4-mac. You might want to do "sudo port upgrade outdated" before anything else.

I tried the gnuradio-legacy port, it installed fine, but unfortunately the plug-in port I need to install, gr-osmosdr, doesn't yet recognize that port. I'll still be eagerly looking for a solution to this issue as I'd also like to install gqrx, with requires gnuradio 3.7.

I checked 'port outdate' a few hours ago and it reported everything was up to date (at least as of the 5th due to the sync issue).

I'll still be available to help out if you need me to test anything, but we may need to wait for this sync issue to be resolved so we can be sure I'm up to date.

[b.forbort@…]

Correction: gr-osmosdr-legacy was created to match gnuradio-legacy. I'll give it a shot!

[michaelld (Michael Dickens)]

Yes, I intentionally made the "legacy" versions compatible. I do hope those work for you. I find it strange that gnuradio-legacy works, but gnuradio (3.7.0 release) does not -- but, 10.6 is quite a bit different than 10.8. Anyway, I'll look through the logs and see if anything comes to mind.

[michaelld (Michael Dickens)]

You might want to try gnuradio-devel, since it contains fixes from the latest release. I doubt it will do the trick, but who knows? You will, of course, have to match gr-osmosdr with the correct gnuradio install.

I'll also look into making a gqrx port; it will require gnuradio 3.7 API, so we'll keep working on that here.

[b.forbort@…]

Replying to michaelld@…:

[...] I find it strange that gnuradio-legacy works, but gnuradio (3.7.0 release) does not -- but, 10.6 is quite a bit different than 10.8.

Likewise. But I just confirmed it. I have gnuradio-legacy installed and gnuradio-companion is up and running. I've already tried gnuradio-devel and it errored out as well, but unfortunately I did not save the log.

I'll continue to watch this ticket and look for solutions.

Also, a gqrx port would be very nice. I'd like to put together a step-by-step youtube video on the RTL-SDR running with a Mac, so the simpler it is, the better.

[michaelld (Michael Dickens)]

When you build "gnuradio" or "gnuradio-devel", can you post the file port dir gnuradio/work/build/CMakeCache.txt? That might help shed some light.

The gqrx trunk/master requires GR 3.7 API, but there is a commit not too far back that uses the 3.6 API. So, I'm trying this out using those to see if /how well it works.

[b.forbort@…]

Replying to michaelld@…:

When you build "gnuradio" or "gnuradio-devel", can you post the file port dir gnuradio/work/build/CMakeCache.txt? That might help shed some light.

I'm running a fresh build now.

It looks like the sync issue has been resolved, and an updated version of gettext is being installed as a dependency.

gettext                        0.18.2.1_0 < 0.18.3_0     

I'll let you know when the build has completed and upload that file if it fails.

[b.forbort@…]

I received the fallowing error after after trying to build:

Error: org.macports.build for port gnuradio returned: command execution failed
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port gnuradio failed

I've attached the CMakeCache.txt file and I'm attempting another clean/build at the moment in case that I was fluke.

[michaelld (Michael Dickens)]

Hmmm .. not much light yet. Can you post the file "`port dir gnuradio`/work/build/gr-blocks/swig/blocks_swig1PYTHON_wrap.cxx"?

[michaelld (Michael Dickens)]

Is your computer's CPU 32-bit native? You can find that info under "About This Mac" or the System Information.app. I'll look through the GR code tomorrow to see if there's a bug. The basic issue is that the SWIG code is using a "size_t" type, which maps to the "long" type, which varies in size depending on the compile (32 or 64 bits), but internally trying to set it to "int" which I believe is always 32 bits within Apple's GCC. I've no idea yet why this is happening.

[b.forbort@…]

It's a 32 bit Core Duo MacBook Pro running Snow Leopard.

[michaelld (Michael Dickens)]

Thanks. It looks like there is a bug in SWIG 2.0.9, which is -way- over my pay grade. I see it in the code generated on my 64-bit CPU, but it works because "size_t" is also 64-bit. Maybe SWIG 2.0.10 fixes it; or maybe reverting back to a prior version does. I'll play around some tomorrow and see what I can come up with. I really don't think this is a GNU Radio programming issue; the GR code looks solid to me.

[michaelld (Michael Dickens)]

I've attached a possible patch for this issue. What you'll need to do is: (1) download the patch (let's say it was downloaded to "~/Downloads/patch-vector-map.diff"; for some other location, use that path and filename in the "patch" command below). Then do:

sudo port clean gnuradio
sudo port patch gnuradio +full
pushd `port dir gnuradio`/work/gnuradio*
patch -p1 < ~/Downloads/patch-vector-map.diff
popd
sudo port build gnuradio +full

and see if that works. If not, please post the new blocks_swig1PYTHON_wrap.cxx file. If it does work, please let me know so that I can push the patch upstream. Thanks for trying this out!

[b.forbort@…]

I've applied the patch and I'm building now. I may have to head to work before it finishes.

[b.forbort@…]

After Patch

[b.forbort@…]

build failed with the fallowing error:

:info:build [ 67%] Built target _blocks_swig0
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio/gnuradio/work/build'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio/gnuradio/work/build'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio/gnuradio/work/build" && /usr/bin/make -j2 -w all VERBOSE=1 
:info:build Exit code: 2
:error:build org.macports.build for port gnuradio returned: command execution failed
:debug:build Error code: CHILDSTATUS 26924 2
:debug:build Backtrace: command execution failed
    while executing
"system -nice 0 $fullcmdstring"
    ("eval" body line 1)
    invoked from within
"eval system $notty $nice \$fullcmdstring"
    invoked from within
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
:info:build Warning: targets not executed for gnuradio: org.macports.build

blocks_swig1PYTHON_wrap.2.cxx​ attached

[michaelld (Michael Dickens)]

It looks like there was no patch applied. Did the "patch -p1" work?

[michaelld (Michael Dickens)]

Forget that patch. It does not pass "make test". I'm working on another one.

[michaelld (Michael Dickens)]

Did anything ever happen with this issue? I doubt I can fix SWIG, but maybe I can track down a ticket or something.

[michaelld (Michael Dickens)]

Did anything ever happen with this issue?

[michaelld (Michael Dickens)]

I just updated SWIG to 3.0.0 in r118180, which fixes a number of C++ <-> Python bugs. Maybe this new version will work for you? You'll need to do:

sudo port selfupdate
sudo port clean "gnuradio*"
sudo port install gnuradio

[michaelld (Michael Dickens)]

I'm closing this ticket as "fixed" by the 3.0 update, since I have heard nothing back (OP timeout). If this is in error, please reopen the ticket and post a new error log.

[michaelld (Michael Dickens)]

In handling another support ticket, I confirm that this issue still occurs. A possible solution is to comment out the 9 lines of code in gr_types.i towards the end of that file, involving "#ifdef SIZE_T_32". It seems like SWIG might actually be doing the right thing with std::vector<size_t> now with 3.0, probably has been for a while back in the 2.0.10+ series if not earlier. We're testing out this change to see if it is robust across various OSs and SWIG versions.

[cooljeanius (Eric Gallager)]

Cc Me!