discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] cmake build


From: Ben Reynwar
Subject: Re: [Discuss-gnuradio] cmake build
Date: Sun, 11 Sep 2011 22:36:00 -0700

On Sun, Sep 11, 2011 at 11:09 AM, Josh Blum <address@hidden> wrote:
>
>
> On 09/11/2011 04:37 AM, Michael Dickens wrote:
>> 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
>>
>>
>
> 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 :-)
>
> 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
>

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<char>, std::allocator<char> >, bool, int, int)in
audio_osx_source.cc.o
      audio_osx_source::audio_osx_source(int, std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, bool, int, int)in
audio_osx_source.cc.o
      audio_osx_sink::audio_osx_sink(int, std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, bool, int, int)in
audio_osx_sink.cc.o
      audio_osx_sink::audio_osx_sink(int, std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, 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<char>, std::allocator<char> >, bool, int, int)in
audio_osx_source.cc.o
      audio_osx_source::audio_osx_source(int, std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, bool, int, int)in
audio_osx_source.cc.o
      audio_osx_sink::audio_osx_sink(int, std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, bool, int, int)in
audio_osx_sink.cc.o
      audio_osx_sink::audio_osx_sink(int, std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]