[Top][All Lists]
[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
- Re: [Discuss-gnuradio] cmake build, Ben Reynwar, 2011/09/10
- Re: [Discuss-gnuradio] cmake build, Michael Dickens, 2011/09/10
- Re: [Discuss-gnuradio] cmake build, Michael Dickens, 2011/09/10
- Re: [Discuss-gnuradio] cmake build, Ben Reynwar, 2011/09/11
- Re: [Discuss-gnuradio] cmake build, Josh Blum, 2011/09/11
- Re: [Discuss-gnuradio] cmake build, Michael Dickens, 2011/09/11
- Re: [Discuss-gnuradio] cmake build, Josh Blum, 2011/09/11
- Re: [Discuss-gnuradio] cmake build,
Ben Reynwar <=
- Re: [Discuss-gnuradio] cmake build, Josh Blum, 2011/09/12
Re: [Discuss-gnuradio] cmake build, Josh Blum, 2011/09/10