Boost 1.40 won't build on OSX 10.6

Ed_Criscuolo · November 18, 2009, 5:43am

I recently upgraded to a new MacBook Pro with OSX 10.6 and can’t
get GnuRadio 3.2.2 to configure because it wants Boost >=1.35 and
I have Boost 1.33. When I try to upgrade Boost using macports,
it fails with the following (long) error:

Error: Target org.macports.build returned: shell command " cd
“/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_boost/work/boost_1_40_0”
&& bjam -j2 -d2 --layout=tagged --debug-configuration
–ignore-site-config --user-config=user-config.jam --without-python
–without-mpi -sBZIP2_INCLUDE=/opt/local/include
-sBZIP2_LIBPATH=/opt/local/lib -sZLIB_INCLUDE=/opt/local/include
-sZLIB_LIBPATH=/opt/local/lib " returned error 1

I tried cleaning out boost, boost-jam, and jam and re-installing
them, but no luck. Anyone else have any luck running 3.2.2
on OSX 10.6?

@(^.^)@ Ed

Ed_Criscuolo · November 18, 2009, 4:18pm

Hi Ed - The 3.2.2 release cannot easily be made to be fully working on
OSX 10.6, but the complexity depends mostly on whether your computer’s
CPU is 32- or 64-bit.

If your computer’s CPU is 32-bit then I think all components except
gr-audio-osx should compile & execute without change. You might need
to specify “–with-md-cpu=i386” to force the use of the correct FIR
filter code (I don’t have a 32-bit CPU to test this on).
If your computer’s CPU is 64-bit, then you have 3 primary choices to
get GNU Radio going (at all) on 10.6:

If you insist on using GNU Radio 3.2.2, then you’ll want to limit
compilation to just 32-bit mode by setting the CFLAGS (et.al.) to
include “-arch i386” (I think) – and do without native audio support
(gr-audio-osx; audio issues are fixed in the GIT master, so you can
always diff those files & make the mods to the 3.2.2 release & hope
for the best); or
Move to the GIT master, and limit compilation to just 32-bit mode
– and you should get full GNU Radio functionality (assuming you can
get all of the background dependencies installed, e.g., via MacPorts).
Move to the GIT master, do 64-bit compilation – and do with a GUI.

The GIT master has been updated to allow for 32- or 64-bit compiling
on OSX, and should support 10.4, 10.5, and 10.6 – except the GUI
won’t work under x86_64 yet (64-bit, any supported OS version; it’s a
wxpython issue, and the wx folks are working on full 64-bit OSX
support for the next [2.9.0] release). The current wxgui should work
on i386 (32-bit, any supported OS version).

I hope this isn’t too confusing! Ask more if this doesn’t help
enough. - MLD

Ed_Criscuolo · November 18, 2009, 6:23pm

On Wed, Nov 18, 2009 at 10:12:35AM -0500, Michael D. wrote:

get GNU Radio going (at all) on 10.6:
of the background dependencies installed, e.g., via MacPorts).
I hope this isn’t too confusing! Ask more if this doesn’t help enough. -
I’m confused!

Michael, can you help me understand what the problems are, and what,
if anything, we can do on the GNU Radio side to resolve them? It
sounds like some of these problems may have more to do with
external dependencies than with GNU Radio itself.

The guts of GNU Radio definitely run on x86 and x86-64, so I’m not
sure what the “64-bit issue” is on OS/X. Last I checked, we ran on
64-bit PPC on Fedora too.

Thanks!
Eric

Ed_Criscuolo · November 18, 2009, 8:17pm

Michael D. wrote:

Hi Ed - The 3.2.2 release cannot easily be made to be fully working on
OSX 10.6, but the complexity depends mostly on whether your computer’s
CPU is 32- or 64-bit.

It’s a brand new MacBook Pro with 2.8 GHz Intel Core2 Duo, so as far as
I know it’s 64-bit.

If your computer’s CPU is 64-bit, then you have 3 primary choices to
get GNU Radio going (at all) on 10.6:

If you insist on using GNU Radio 3.2.2,

This is preferred…

then you’ll want to limit

compilation to just 32-bit mode by setting the CFLAGS (et.al.) to
include “-arch i386” (I think) – and do without native audio support

Sound’s not critical, so this has possibilities. But I can’t even get
past the ./configure until I get Boost 1.40 to install.

Move to the GIT master, and limit compilation to just 32-bit mode
– and you should get full GNU Radio functionality (assuming you can
get all of the background dependencies installed, e.g., via MacPorts).

Also has possibilities. But MacPorts has been the real problem so far.
I can’t get the dependencies (specifically Boost >=1.35) to install.
And I’ve now broken my previously-working GnuRadio 3.1.3
installation.

Move to the GIT master, do 64-bit compilation – and do with a GUI.

Not really acceptable for our application. We want the GUI stuff.

I hope this isn’t too confusing! Ask more if this doesn’t help
enough. - MLD

I really need to figure out the problem with the MacPorts dependencies
not installing. Any clues would be appreciated. I’m sure this has to
do with the fact that I used Apple’s migration assistant to move my
account onto the new laptop (including the MacPorts stuff and GR 3.1.3).
My old laptop was running 10.4, and now I’m afraid I’ve got a mix of
32 and 64 bit stuff installed. But 3.1.3 and GRC 0.69 DID run after
the migration.

@(^.^)@ Ed

Ed_Criscuolo · November 18, 2009, 8:31pm

On Wed, Nov 18, 2009 at 02:22:27PM -0500, Michael D. wrote:

Radio -release 3.2.2- does not have these recent GIT master changes for

The issues w/r.t. 10.6 &/or 64-bit are instead with the dependencies
wxWidgets and wxPython: Up through the 2.8.10 series, the WX* codebase
was 32-bit compatible on OSX but would fail when compiled as 64-bit
(and, OSX won’t allow one to mix & match 32- and 64-bit libraries and
applications). Starting with WX* 2.9.0, the codebase will be both 32-
bit and 64-bit compatible on OSX 10.5 or 10.6 < http://wxwidgets.org/ >;
wxWidgets 2.9.0 has been released, but wxPython has yet to catch up
before “we” can test them out with GNU Radio (via MacPorts or otherwise)

I hope this note clarifies your issues; if not, ask more. - MLD

Thanks for the detailed answer!

Eric

Ed_Criscuolo · November 18, 2009, 8:26pm

On Nov 18, 2009, at 12:06 PM, Eric B. wrote:

Michael, can you help me understand what the problems are, and what,
if anything, we can do on the GNU Radio side to resolve them? It
sounds like some of these problems may have more to do with
external dependencies than with GNU Radio itself.

The guts of GNU Radio definitely run on x86 and x86-64, so I’m not
sure what the “64-bit issue” is on OS/X. Last I checked, we ran on
64-bit PPC on Fedora too.

“We” made numerous Darwin-specific changes to the GNU Radio GIT master
recently to resolve 10.6 and 64-bit compiling issues (mostly debugging
printouts, by moving “fprintf(stderr,…)” to “std::cerr << …”).
Hence the GNU Radio -GIT master- should now be compatible with OSX
10.4, 10.5, or 10.6 as 32-bit or 64-bit. I have successfully tested
GNU Radio in 32-bit on each of these (Intel only, but that shouldn’t
make a difference), and in 64-bit on 10.6, using MacPorts for all
installable dependencies (NB for 10.6: see the last real paragraph
below).

I believe that Ed was asking specifically about the 3.2.2 release.
GNU Radio -release 3.2.2- does not have these recent GIT master
changes for both 10.6 and 64-bit OSX, but most of 3.2.2 should compile
as 32-bit since it was originally (inadvertently) designed to compile
as 32-bit – only gr-audio-osx needs changes to compile under 10.6
because Apple changed the CoreAudio API. To the best of my knowledge,
GNU Radio was never compiled as 64-bit under 10.5 (or 10.4,if that’s
possible) … hence it’s only with the move to 10.6 that these bit-
width issues came up – and were promptly addressed.

Thus, to summarize, assuming we’re talking about the GNU Radio GIT
master: The issues are not with GNU Radio.

The issues w/r.t. 10.6 &/or 64-bit are instead with the dependencies
wxWidgets and wxPython: Up through the 2.8.10 series, the WX* codebase
was 32-bit compatible on OSX but would fail when compiled as 64-bit
(and, OSX won’t allow one to mix & match 32- and 64-bit libraries and
applications). Starting with WX* 2.9.0, the codebase will be both 32-
bit and 64-bit compatible on OSX 10.5 or 10.6 < http://wxwidgets.org/

; wxWidgets 2.9.0 has been released, but wxPython has yet to catch
up before “we” can test them out with GNU Radio (via MacPorts or
otherwise)

I hope this note clarifies your issues; if not, ask more. - MLD

Ed_Criscuolo · November 18, 2009, 9:43pm

Ed Criscuolo wrote:

… But MacPorts has been the real problem so far.
I can’t get the dependencies (specifically Boost >=1.35) to install.

I found that problem with Boost came from zlib and bzip2. By
reinstalling these with the +universal variant specified
Boost 1.40 was able to install successfully.

Now working on the other missing dependencies.

Also got a message that usrp2 was not configured because its
only supported on Linux. Is this true?

@(^.^)@ Ed

Ed_Criscuolo · December 4, 2009, 9:01pm

Michael D. wrote:

Move to the GIT master, and limit compilation to just 32-bit mode
– and you should get full GNU Radio functionality (assuming you can
get all of the background dependencies installed, e.g., via MacPorts).

Michael,

I’ve decided to take this approach for now. I’ve cloned the latest
git master, but I’m a total beginner at git. Where’s the best place
to insert the “-arch i386” into CFLAGS to force a 32-bit build? Is
it as simple as

./bootstrap
./configure
“make CFLAGS=”-arch i386"
make check
sudo make install

or does it need to go in as a switch to “configure”?

By the way, we missed you at the “GnuRadio Summit '09”
last night after the SDR '09 sessions.

@(^.^)@ Ed

Ed_Criscuolo · November 18, 2009, 9:56pm

On Wed, Nov 18, 2009 at 03:37:02PM -0500, Ed Criscuolo wrote:

Also got a message that usrp2 was not configured because its
only supported on Linux. Is this true?

At this time, yes.

It’ll be fixed as part of the VRT work (Virtual Radio Transport; AKA
VITA-49).
Progress is being made on this…

Eric

Ed_Criscuolo · December 8, 2009, 2:15am

On Fri, Dec 04, 2009 at 08:55:10PM -0500, Michael D. wrote:

sudo make install
directing from ‘make’. I haven’t tried this approach, but I see no
reason it won’t work. Do let me/the list know, and good luck! - MLD

This is the preferred way:

./bootstrap
./configure CFLAGS="-arch i386" CXXFLAGS="-arch i386"

This way configure writes the CFLAGS and CXXFLAGS values into the
generated Makefiles.

Eric

Ed_Criscuolo · December 5, 2009, 3:00am

On Dec 4, 2009, at 2:56 PM, Ed Criscuolo wrote:

or does it need to go in as a switch to “configure”?

Into configure, or before then; after bootstrap & before make. You
can just

export CFLAGS="-arch i386"

and so forth, then run ‘configure’ & it’ll pick up your shell
environment. I don’t think you can easily change the build
environment directing from ‘make’. I haven’t tried this approach, but
I see no reason it won’t work. Do let me/the list know, and good
luck! - MLD