Re: Intel Mac GNU Radio Install Update Soon

GNU Radio
1

Hello All,

I am currently trying to get gnuradio-core running on an Intel
MacBook. I had a go at installing gnuradio-core today, and after much
hacking managed to get close (but not quite all the way).

Here is a brief summary of my progress (hopefully this will be useful
to someone!).

I am using a MacBook 2 GHz Intel Core Duo running Mac OS X 10.4.6 and
using gcc 4.0.1 to build.

I started off with Jon’s excellent web page:
http://staff.washington.edu/jon/gr-osx/gr-osx-core.html#build

As much as possible, I tried to use Darwin ports packages rather than
install source from scratch (convenience rather than anything else).
I found I could install the following pre-requisites from Darwin
Ports: subversion, autonconf, automake, libtool, pkgconfig, swig,
boost, boost-jam, and cppunit.

Python24 died as did Numeric and FFTW. FFTW was an issue with the
latest version 3.1.1 and gcc 4.0.1. There was a workaround, but it
was a bit kludgy and involved disabling all optimizations during the
compilation. I submitted a bug report to Darwin Ports and the FFTW
folks, so hopefully they’ll look into it. I still need to look into
why the Python package didn’t work.

I installed the following packages from source tarballs: fftw3.0.1,
numeric, and python24. FFTW I installed using the --enable-float and
–disable-fma configure options. There were no problems compiling
version 3.0.1.

My goal was to get gnuradio-core installed, so I stopped there as far
as pre-requisites. Next I was on to compiling and installing GNU
Radio Core.

I checked out the source, and went through the usual bootstrap,
configure, compile cycle.

There were a few gotchas here:

  • As Jan had pointed out in an earlier post “.align 16” doesn’t work
    too well
    on the Intel Macs, so I converted to “.align 4” for all of the source
    files
    in src/lib/filter.

  • There was a write permissions error for “Makefile.gen” and
    “general_generated_i” so I chmoded these files to allow user write.

After all of this, compilation went through to almost the last stage,
when I got the message at the bottom of the email. I’m going to leave
it at this for now. Any ideas/insights are most welcome!

I have put together some scripts to automate most of the installation
steps. I’d be happy to pass them on to anyone who would find them
useful. I am also happy to test out anyone else’s installation scripts.

Cheers,

Dave.

g++ -DHAVE_CONFIG_H -I. -I. -I…/… -g -O2 -Wall -Woverloaded-
virtual -c bug_work_around_6.cc -MT bug_work_around_6.lo -MD -MP -
MF .deps/bug_work_around_6.TPlo -fno-common -DPIC -o .libs/
bug_work_around_6.o
bug_work_around_6.cc:3: warning: ‘gr_bug_work_around_6’ defined but
not used
/bin/sh …/…/libtool --mode=link g++ -g -O2 -Wall -Woverloaded-
virtual -o libgnuradio-core.la -rpath /Users/dl99/Documents/
projects/svpn/build/gr/lib -version-info 0:0:0 bug_work_around_6.lo
filter/libfilter.la g72x/libccitt.la general/libgeneral.la io/
libio.la missing/libmissing.la omnithread/libomnithread.la reed-
solomon/librs.la runtime/libruntime.la -L/Users/dl99/Documents/
projects/svpn-cm/build-scripts/…/…/svpn/build/extern/lib -lfftw3f -lm
g++ -dynamiclib -single_module -flat_namespace -undefined suppress -
o .libs/libgnuradio-core.0 .libs/bug_work_around_6.o -all_load
filter/.libs/libfilter.a g72x/.libs/libccitt.a general/.libs/
libgeneral.a io/.libs/libio.a missing/.libs/libmissing.a
omnithread/.libs/libomnithread.a reed-solomon/.libs/librs.a
runtime/.libs/libruntime.a -L/Users/dl99/Documents/projects/svpn-cm/
build-scripts/…/…/svpn/build/extern/lib /Users/dl99/Documents/
projects/svpn-cm/build-scripts/…/…/svpn/build/extern/lib/
libfftw3f.a -L/Users/dl99/Documents/projects/svpn/build/gr/lib -L/opt/
local/lib -lm -install_name /Users/dl99/Documents/projects/svpn/
build/gr/lib/libgnuradio-core.0 -Wl,-compatibility_version -Wl,1 -Wl,-
current_version -Wl,1.0
ld: warning -L: directory name (/Users/dl99/Documents/projects/svpn/
build/gr/lib) does not exist
ld: multiple definitions of symbol ___divdi3
/usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a(_divdi3.o) private
external definition of ___divdi3 in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/…/…/…/libgcc_s.10.4.dylib
(_divdi3_s.o) definition of ___divdi3
ld: multiple definitions of symbol ___udivdi3
/usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a(_udivdi3.o) private
external definition of ___udivdi3 in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/…/…/…/libgcc_s.10.4.dylib
(_udivdi3_s.o) definition of ___udivdi3
ld: multiple definitions of symbol ___umoddi3
/usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a(_umoddi3.o) private
external definition of ___umoddi3 in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/…/…/…/libgcc_s.10.4.dylib
(_umoddi3_s.o) definition of ___umoddi3
/usr/bin/libtool: internal link edit command failed
make[4]: *** [libgnuradio-core.la] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

2

Dave - You can do all of the background install using DarwinPorts,
but, as you found out, FFTW has some issues. The problem is not in
optimization, but rather in the way Apple has tweaked GCC’s use of
“pentium-pro” for the architecture. Most files compile just fine but
a few (4-5) need this option removed for correct compilation (with
optimization -03 still on, which is good).

I have submitted patches to Eric to fix the .align issue - some
compilers define that number in log2 while others use linear. I’d be
happy to ship you my diff’s if you have time to try them out.

As of 1 week ago, there were no issues with gnuradio-core other than
the .align and a .global issue in the same .S files in gnuradio-core/
src/lib/filter . Everything compiled and installed correctly on a
MacBook Pro. Admittedly, Apple has released XCode 2.3 since then, so
if you’re using that version there might be an issue. We haven’t
finished testing under XCode 2.3 yet, maybe due to lack of time.

Permissions are generally a local-computer issue, not one of how they
are stored in the CVS or SVN repository.

I’d be willing to bet that the compile issue is some combination of
your shell environment and LIBTOOL not working together. -Unless-
it’s XCode 2.3, then it’s most likely not a Mac-Intel issue.

I have updated my install guide < http://www.nd.edu/~mdickens/
GNURadio/ > to include the latest changes for FFTW to compile using
DarwinPorts on an Intel-Mac.

I’m happy to help you debug your compile issue, probably off-list is
best. - MLD

3

On my install guide, check out the .tcshrc additions … you can
certainly port them to BASH or whatever. They represent very
precisely what DarwinPorts and GNURadio need to compile and install
under OSX (PPC or Intel). While you can do the install by hand, or
via some custom method, I’ve found that DarwinPorts is quite reliable
and the few issues can be easily overcome with some quick file mods.

Compare the environment variables to what you have, or I can easily
do that and make suggestions … just send me a “printenv” from your
desired shell (off-list is probably best) … weed out anything you
feel is sensitive if you want, but I’ll use discretion as necessary.

machine. You can manually force it to tune for the pentium-m
(which seems to be the best option for now) by configuring --with-
gcc-arch=pentium-m

I haven’t tried out the configure option, but that looks like it
might make things a bit easier.

Interesting. My testing found that the kernel/trig.c file just
needed to be told the correct architecture (or no architecture), but
leaving optimization was OK. I hadn’t tried the --with-gcc-
arch=pentium-m configure option, but I’ll try that next time I have
with an Intel-Mac around.

I have submitted patches to Eric to fix the .align issue - some
compilers define that number in log2 while others use linear. I’d
be happy to ship you my diff’s if you have time to try them out.

Great! I would be happy to.

They’re appended. You need to put the M4 file into gnuradio-core/
config, then cd into gnuradio-core and do “patch -p0 < (wherever)/gr-
core_cvs_diff_u.txt”. Then you’ll need to bootstrap, configure, and
make in whatever way you usually do.

NOTE1: These are untested, but should work properly. If you decide
to test them, please report back to me or the list if/how they work,
and/or corrections if they don’t work.

NOTE2: These changes affect -any- Intel-based computer, not just Mac’s.

I have updated my install guide < http://www.nd.edu/~mdickens/
GNURadio/ > to include the latest changes for FFTW to compile
using DarwinPorts on an Intel-Mac.

Great! I’ll try it out.

I appreciate any comments and feedback I can get on Mac installs.
The scripts I have made work well for most people, though there are
always exceptions - mostly due to strange shell environments or an
old LIBTOOL version not working with Darwin.

Good luck! - MLD

ps> gr-audio-osx will be functional on an Intel-Mac in the next
couple of days. I’m fixing bugs almost as I write. I’ll post to the
list when it’s working better.

4

On Thu, Jun 01, 2006 at 04:19:38PM -0400, Michael D. wrote:

I have submitted patches to Eric to fix the .align issue - some
compilers define that number in log2 while others use linear. I’d
be happy to ship you my diff’s if you have time to try them out.

Great! I would be happy to.

Hi Michael,

I’ve applied a variant of your patch and tested in on x86 and x86-64.

Turns out that

.p2align X

Always aligns to 2^X. So all I had to do was change the

.align 16 -> .p2align 4
.align 8 -> .p2align 3

Can you please update gnuradio-core and test on your Mac platforms?

[FYI, found this out by checking the GAS info file.]

Thanks,
Eric

5

Michael,

Thanks for the information, that is great.

On Jun 1, 2006, at 3:24 PM, Michael D. wrote:

Dave - You can do all of the background install using DarwinPorts,
but, as you found out, FFTW has some issues. The problem is not in
optimization, but rather in the way Apple has tweaked GCC’s use of
“pentium-pro” for the architecture. Most files compile just fine
but a few (4-5) need this option removed for correct compilation
(with optimization -03 still on, which is good).

The FFTW folks got back to me. Here is what they had to say:

There are two known problems on the Intel Macs.

First, Apple's gcc 4.0.1 on Intel has a bug that causes it to crash

when compiling our kernel/trig.c file … the workaround is to
compile this file without optimization:
cd kernel; make CFLAGS=" " trig.lo

Second, our CPU detection currently doesn't work for that machine.

You can manually force it to tune for the pentium-m (which seems to
be the best option for now) by configuring --with-gcc-arch=pentium-m

I haven’t tried out the configure option, but that looks like it
might make things a bit easier.

I have submitted patches to Eric to fix the .align issue - some
compilers define that number in log2 while others use linear. I’d
be happy to ship you my diff’s if you have time to try them out.

Great! I would be happy to.

As of 1 week ago, there were no issues with gnuradio-core other
than the .align and a .global issue in the same .S files in
gnuradio-core/src/lib/filter . Everything compiled and installed
correctly on a MacBook Pro. Admittedly, Apple has released XCode
2.3 since then, so if you’re using that version there might be an
issue. We haven’t finished testing under XCode 2.3 yet, maybe due
to lack of time.

I haven’t updated XCode yet. I’ll do that and give it a go.

Permissions are generally a local-computer issue, not one of how
they are stored in the CVS or SVN repository.

I’d be willing to bet that the compile issue is some combination of
your shell environment and LIBTOOL not working together. -Unless-
it’s XCode 2.3, then it’s most likely not a Mac-Intel issue.

OK. I’ll check it out.

I have updated my install guide < http://www.nd.edu/~mdickens/
GNURadio/ > to include the latest changes for FFTW to compile using
DarwinPorts on an Intel-Mac.

Great! I’ll try it out.

I’m happy to help you debug your compile issue, probably off-list
is best. - MLD

Sounds good. Thanks again for your help. Much appreciated.

Dave.

6

Michael D. wrote:

On my install guide, check out the .tcshrc additions … you can
certainly port them to BASH or whatever. They represent very precisely
what DarwinPorts and GNURadio need to compile and install under OSX (PPC
or Intel). While you can do the install by hand, or via some custom
method, I’ve found that DarwinPorts is quite reliable and the few issues
can be easily overcome with some quick file mods.

Thanks, that is great. I had entered the FFTW issue as a bug in Darwin
Ports yesterday and it looks like they will be adding the workaround to
the distribution. So that should be one less thing to worry about.

Thanks for the scripts. They look great. I am working on the install
with your scripts and Eric’s new additions to the codebase now. I’ll
let you know how it goes.

Cheers,

Dave.

7

On Fri, Jun 02, 2006 at 10:19:03PM -0400, Dave wrote:

Dave.
Thanks for the feedback!

Eric

8

Eric B. wrote:

Turns out that

.p2align X

Always aligns to 2^X. So all I had to do was change the

.align 16 -> .p2align 4
.align 8 -> .p2align 3

Can you please update gnuradio-core and test on your Mac platforms?

Eric, Michael,

The new code and scripts work fine on my Intel Mac.

Thanks!

Dave.

9

Thanks a lot for writing that install guide for Mac OS X. It works
great.

Thanks! Good to hear it’s being used successfully by folks outside
of UND.

Here some updates on my experience with it on a Macbook 2GHz
with XCode 2.3:

  • The USRP section is outdated. You don’t need to download it
    seperatly since the checkout script has been changed.

It sure is. I’ll update this sooner rather than later.

  • Since the new Macbooks have dual core, one can add a -j2 to each
    make command. That will speed up compilation because it creates two
    gcc instances at a time.

This would come in the ./configure stage. Probably a switch
statement somewhere which could be expanded to include the intel-mac
‘uname’ specs.

Eric - Any quick idea where to look for this to change it? - MLD

10
  • Since the new Macbooks have dual core, one can add a -j2 to each
    make command. That will speed up compilation because it creates two
    gcc instances at a time.

This would come in the ./configure stage. Probably a switch
statement somewhere which could be expanded to include the intel-
mac ‘uname’ specs.

Answering my own issue here: “make -j2” would create 2 parallel
"make"s, if I read the manpage correctly. Is this what you were
getting at before? If so, then it’s probably easier to do “alias
make=‘make -j2’” in your BASH shell (“alias make ‘make -j2’” in
TCSH). Good idea … I’ll add a comment about that when I get there.

  • MLD
11

Hi Michael,

Thanks a lot for writing that install guide for Mac OS X. It works
great. Here some updates on my experience with it on a Macbook 2GHz
with XCode 2.3:

  • The USRP section is outdated. You don’t need to download it
    seperatly since the checkout script has been changed.
  • Since the new Macbooks have dual core, one can add a -j2 to each
    make command. That will speed up compilation because it creates two
    gcc instances at a time.
  • I converted the tcsh scripts to bash. Here is what I have in my
    .profile. This assumes that you use darwinports:

export LDFLAGS="-L/opt/local/lib ${LDFLAGS}"
export PATH=/opt/local/bin:${PATH}
export MANPATH=/opt/local/share/man:${MANPATH}
export INFOPATH=/opt/local/share/info:${INFOPATH}
export CPATH=/opt/local/include:${CPATH}
export
PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:/usr/local/lib/pkgconfig:${PKG_CONFIG_PATH}

p_v_f=python -V 2>&1 | sed -e 's@Python @@g' | sed -e 's@\.@ @2' | awk '{print $1}'
export PYTHON_VERSION=$p_v_f
export PYTHON_ROOT=which python | sed -e 's@/bin/python@@g'
export
PYTHONPATH=${PYTHON_ROOT}/lib/python${PYTHON_VERSION}/site-packages
if [ ${PYTHON_ROOT} != “/usr/include” ]; then
export
PYTHONPATH=${PYTHONPATH}:/usr/local/lib/python${PYTHON_VERSION}/site-packages
fi

Could that howto install script maybe be moved into the wiki, once the
new wiki system is up and running?

Thomas

12

On Mon, Jul 31, 2006 at 03:59:23PM -0400, Michael D. wrote:

getting at before? If so, then it’s probably easier to do “alias
make=‘make -j2’” in your BASH shell (“alias make ‘make -j2’” in
TCSH). Good idea … I’ll add a comment about that when I get there.

  • MLD

The user can invoke make with -j N if they like. Don’t try to
automate this.

Eric

13

Thomas S. wrote:

Also, increasing to -j3 or -j4 might even increase the compile
performance since some of the make processes might be doing some
intensive IO work, thus the CPUs are free for compiling. I only
recently learnt that (thank you, Greg)…

I’ve read that the thumb rule (wish I had a cite but don’t remember) is
to use the number of CPUs (or CPU cores) available + 1. This keeps all
the CPUs busy plus has an extra process to fill in cycles when there are
I/O stalls.

-Johnathan

14

Thomas S. wrote:

A quick note of caution: I found out that sometimes compiling with -j2
gets errors, then restarting the process without -j2 compiles without
any errors. I assume that it is some dependency problems because one
of the processes did not finish yet.
“This should never happen”, but frequently does. The whole point of
makefiles is to figure out dependencies and “do stuff”. If you know what
depends on what, figuring out what can be done in parallel is a trivial
task. If that breaks the makefile, there is probably some assumption
about build order coded into the makefile. If you care about what you
are building, this is probably worth tracking down. Just like running
your multi-threaded application for the first time on a multi-processor
box. If it breaks in new and interesting ways, there’s something you
forgot :-).

Cheers,
Jan

15

I agree, we should not automate this, though a note in a “how to
install on a macbook” would be nice since a lot of people don’t know
about that option.

A quick note of caution: I found out that sometimes compiling with -j2
gets errors, then restarting the process without -j2 compiles without
any errors. I assume that it is some dependency problems because one
of the processes did not finish yet.

Also, increasing to -j3 or -j4 might even increase the compile
performance since some of the make processes might be doing some
intensive IO work, thus the CPUs are free for compiling. I only
recently learnt that (thank you, Greg)…

Thomas

16

I am currently rebuilding everything on a mac mini and post the
failing logs here…

Thomas

17

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio