Cmake build

GNU Radio
21

Unless Josh changed something recently, the cmake build (with volk
disabled) worked for me under 10.6.8, XCode 3.2.3, 64-bit. It looks
like Ben is doing this testing on 10.5.8, XCode 3.1.4 – which by
default will use 32-bit for either PPC or Intel compiling, and, really,
getting 64-bit was somewhat of a challenge until 10.6. A “fat” or
“universal” build o 10.5 meant 32-bit PPC and Intel merged into a single
file. IIRC, gcc under 10.5.8 could be coerced into doing 64-bit, but
doing so was much more reliable using Apple’s interface. All of that
changed with 10.6, since 64-bit was the default for any capable
processor (and, all processors were Intel, and mostly legacy ones were
32-bit only), and “universal” meant (and still means) both 32- and
64-bit Intel compiling (merged). Given that “we” designed the GR
autotools build to work on OSX with both 32- and 64-bit compiling,
starting early in 10.5 days, I’m glad that that build still works
correctly.

With the above I mind, it would probably help to know from Ben what
“arch” and “uname -a” return. Looking at Josh’s pastebin change, I would
bet that CMAKE_SYSTEM_PROCESSOR is “i386” (it is for all Intel OSX
builds, as far as I know). But, under 10.5, CMAKE_SYSTEM_PROCESSOR
should probably be “i386”, not “x86_64” – but, it really depends on
what Ben’s system is / provides. - MLD

22

float_dotprod_sse64.S:121:bad register name `%rsi)’

Is the build correctly detecting your machine arch (you have a x86-64)?

If so, gcc may also need to build those sources w/ -m64,
here is my best guess for a correction:

-josh

23

On Sun, Sep 11, 2011 at 11:09 AM, Josh B. [email protected] wrote:

doing 64-bit, but doing so was much more reliable using Apple’s
would bet that CMAKE_SYSTEM_PROCESSOR is “i386” (it is for all Intel
compiler’s bit width in filter. I think its a lot more robust:

http://gnuradio.org/cgit/jblum.git/log/?h=detect_x86_type

-josh

Yep, that fixed the problem.

In case anyone wants to continuing playing “get the cmake build
working on an obsolete macbook” game, here is the next error I get. I
should emphasize that I don’t need to get this working, so it’s only
of importance if you think that getting the cmake build working on a 4
year old macbook is a worthwhile goal :).

[ 74%] Building CXX object
gr-audio/lib/CMakeFiles/gnuradio-audio.dir/osx/audio_osx_sink.cc.o
Linking CXX shared library libgnuradio-audio.dylib
ld warning: duplicate dylib /usr/local/lib/libboost_date_time-mt.dylib
ld warning: duplicate dylib
/usr/local/lib/libboost_program_options-mt.dylib
ld warning: duplicate dylib /usr/local/lib/libboost_filesystem-mt.dylib
ld warning: duplicate dylib /usr/local/lib/libboost_system-mt.dylib
ld warning: duplicate dylib /usr/local/lib/libboost_thread-mt.dylib
Undefined symbols:
“_CloseComponent”, referenced from:
audio_osx_source::~audio_osx_source()in audio_osx_source.cc.o
audio_osx_source::~audio_osx_source()in audio_osx_source.cc.o
audio_osx_source::~audio_osx_source()in audio_osx_source.cc.o
audio_osx_sink::~audio_osx_sink()in audio_osx_sink.cc.o
audio_osx_sink::~audio_osx_sink()in audio_osx_sink.cc.o
audio_osx_sink::~audio_osx_sink()in audio_osx_sink.cc.o
“_OpenAComponent”, referenced from:
audio_osx_source::audio_osx_source(int, std::basic_string<char,
std::char_traits, std::allocator >, bool, int, int)in
audio_osx_source.cc.o
audio_osx_source::audio_osx_source(int, std::basic_string<char,
std::char_traits, std::allocator >, bool, int, int)in
audio_osx_source.cc.o
audio_osx_sink::audio_osx_sink(int, std::basic_string<char,
std::char_traits, std::allocator >, bool, int, int)in
audio_osx_sink.cc.o
audio_osx_sink::audio_osx_sink(int, std::basic_string<char,
std::char_traits, std::allocator >, bool, int, int)in
audio_osx_sink.cc.o
“_FindNextComponent”, referenced from:
audio_osx_source::audio_osx_source(int, std::basic_string<char,
std::char_traits, std::allocator >, bool, int, int)in
audio_osx_source.cc.o
audio_osx_source::audio_osx_source(int, std::basic_string<char,
std::char_traits, std::allocator >, bool, int, int)in
audio_osx_source.cc.o
audio_osx_sink::audio_osx_sink(int, std::basic_string<char,
std::char_traits, std::allocator >, bool, int, int)in
audio_osx_sink.cc.o
audio_osx_sink::audio_osx_sink(int, std::basic_string<char,
std::char_traits, std::allocator >, bool, int, int)in
audio_osx_sink.cc.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [gr-audio/lib/libgnuradio-audio.3.x.x.dylib] Error 1
make[1]: *** [gr-audio/lib/CMakeFiles/gnuradio-audio.dir/all] Error 2
make: *** [all] Error 2

24

On 09/11/2011 10:36 PM, Ben R. wrote:

Undefined symbols:
“_CloseComponent”

Try this one-liner:

Based on this issue:
https://trac.macports.org/ticket/18718

-Josh

25

On 09/11/2011 04:37 AM, Michael D. wrote:

and mostly legacy ones were 32-bit only), and “universal” meant (and
but, it really depends on what Ben’s system is / provides. - MLD

This is only an issue w/ gr-filter where we try to perform arch
detection. The way volk is doing it should always be ok :slight_smile:

I made a branch detect_x86_type on jblum.git, where I try to detect the
compiler’s bit width in filter. I think its a lot more robust:

http://gnuradio.org/cgit/jblum.git/log/?h=detect_x86_type

-josh