For a number of complicated reasons I would like to build GNU Radio with
an older version of Boost. Specifically 1.49.
Thanks,
David
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
boost > 1.35 should work, but 1.49 is, if I remember correctly, an
especially buggy version, especially in Ubuntu.
I guess you wouldn’t ask if there wasn’t a problem, so maybe you want to
elaborate?
On Mon, Aug 17, 2015 at 6:27 AM, David Halls [email protected]
wrote:
Separating the different components which require Boost into separate
Option 2: If GNU Radio specifically requires a different Boost version you
may be able to recompile it and statically link it against this version.
Option 3: Instead of compiling your MATLAB Code into a Shared Library,
compile it into a standalone application which you can launch from your
Python process. This separate standalone should be able to use its own
Boost libraries without problems then. There are Python libraries which can
read and write MAT-files so you can relatively efficiently pass in- and
outputs from and to that standalone application through MAT-files."
This sounds like good advice. Option 2 sounds the most sane.
I am calling MATLAB compiled code from within GNURadio C++ blocks.
MATLAB compiled code uses a specific version of Boost, and they are
still using 1.49, even with their latest release. I get a the trace
below when I try to run the MATLAB code on newer GNURadio/Ubuntu/Boost
though it works fine on my old (ancient) GNURadio/Ubuntu/Boost build
where the Boost versions match. (Also included is MathWorks take on it).
I was reticent to give all the details because previous MATLAB questions
have left the community running for the hills, saying I should write
everything directly in C++ etc, but there are lots of reasons we can’t
do this, for now!
Thanks,
David
(python2:16446): IBUS-WARNING **: The owner of
/home/gnuradio/.config/ibus/bus is not root!
Using Volk machine: avx_64_mmx_orc
Attempting to initialise the MCR application…
Attempting to initialise the libdla application…
Segmentation violation detected at Tue Jun 23 15:25:36 2015
Configuration:
Crash Decoding : Disabled
Default Encoding : UTF-8
GNU C Library : 2.19 stable
MATLAB Architecture: glnxa64
MATLAB Root : /usr/local/MATLAB/MATLAB_Compiler_Runtime/v81
MATLAB Version : 8.1.0.604 (R2013a)
Operating System : Linux 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15
03:51:08 UTC 2014 x86_64
Processor ID : x86 Family 6 Model 60 Stepping 3, GenuineIntel
A technical support engineer might contact you with further information.
Thank you for your help.** This crash report has been saved to disk as
/home/gnuradio/matlab_crash_dump.16446-1 **
MATLAB is exiting because of fatal error
Done
"The stack trace strongly suggests that the crash is related to a Boost
library version conflict. MATLAB R2013a/MCR v8.1 includes and depends on
Boost 1.49 libraries. In the stack trace we see that in practice your
system’s Boost 1.54 libraries are being accessed however.
These things may occur if you load a MATLAB Compiler Shared Library into
an application which is already making use of this system Boost library.
There are no quick/easy workarounds for such issues other than:
Making sure that all components involved make use of the same Boost
library versions, or
Making sure that the components which require Boost statically link
against the Boost version which they prefer, or
Separating the different components which require Boost into separate
applications.
In further detail:
Option 1: It looks like you are making use of GNU Radio from Python, I
do believe that GNU Radio depends on Boost. You may be able to
(re)compile GNU Radio to make it use Boost 1.49 and where you even
specifically link it to the Boost libraries shipped with the MCR (these
can be found in the bin/glnxa64 directory).
Option 2: If GNU Radio specifically requires a different Boost version
you may be able to recompile it and statically link it against this
version.
Option 3: Instead of compiling your MATLAB Code into a Shared Library,
compile it into a standalone application which you can launch from your
Python process. This separate standalone should be able to use its own
Boost libraries without problems then. There are Python libraries which
can read and write MAT-files so you can relatively efficiently pass in-
and outputs from and to that standalone application through MAT-files."
boost > 1.35 should work, but 1.49 is, if I remember correctly, an
especially buggy version, especially in Ubuntu.
I guess you wouldn’t ask if there wasn’t a problem, so maybe you want to
elaborate?
Best regards,
Marcus
On 08/14/2015 06:00 PM, David Halls wrote:
Hi guys,
For a number of complicated reasons I would like to build GNU Radio with
an older version of Boost. Specifically 1.49.
Thanks,
David
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web:
www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl
This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
I think we can all agree that the community starting to run at the
mention of Matlab is not a good thing - I think there might be
frustration behind this flight instinct, so let’s try to make this a
success story.
I concur with the pretty detailed reply from mathworks; the reason is
likely to be the binary/abi mismatch between the boost GNU Radio/your
native runtime linker uses and the one that the Matlab library needs.
Now, you should be able to specify the boost that cmake uses when
configuring the build process:
cmake -DBOOST_INCLUDEDIR=
-DBOOST_LIBRARY_DIR= …
Also make sure to specify export LD_LIBRARY_DIR containing the same
matlab library dir; otherwise, at runtime your system’s boost will get
linked in, and that will still result in segfaults.
Maybe there is also the option to statically link the Matlab library
before loading it from GNU Radio, instead of doing it the other way
around (which is option 2). To me, that sounds more logically sound,
since it’s Matlab that introduces library dependencies that are
incompatible with your system libraries, because otherwise you might run
into the same problem for other libraries that both Mathworks code and
GNU Radio use and Mathworks ships their own version with. However, I
don’t know if that would even be possible, as I don’t have Matlab around
to test it.
All in all, I also like option 3 from Mathwork’s reply, though I don’t
think the .mat method would work well for streaming like GNU Radio does;
you should be able to just open a file (fopen) and read from it (fread)
in a loop, so that you can get what a file source in GNU Radio writes to
a FIFO; basically, as Matlab pseudocode:
first and then use file sink/source to write/read to/from these.
Of course, a socket- or IPC-based solution might be cleaner, but I don’t
know much popular matlab tools that make it easy to write “real-world
compatible” Matlab code (I think that lack of knowledge of high-quality
well-known libraries might be what leads people to run away as soon as
you mention Matlab).
Best regards,
Marcus
Am 17. August 2015 12:27:25 MESZ, schrieb David Halls [email protected]:
Hi Marcus,
I am calling MATLAB compiled code from within GNURadio C++ blocks.
MATLAB compiled code uses a specific version of Boost, and they are
still using 1.49, even with their latest release. I get a the trace
below when I try to run the MATLAB code on newer
GNURadio/Ubuntu/Boost though it works fine on my old
(ancient) GNURadio/Ubuntu/Boost??? build where the Boost versions
match. (Also included is MathWorks take on it).
I was reticent to give all the details because previous MATLAB
questions have left the community running for the hills, saying I
should write everything directly in C++ etc, but there are lots of
reasons we can't do this, for now!
Thanks,
David
(python2:16446): IBUS-WARNING **: The owner of
/home/gnuradio/.config/ibus/bus is not root!
Using Volk machine: avx_64_mmx_orc
Attempting to initialise the MCR application...
Attempting to initialise the libdla application...
------------------------------------------------------------------------
Segmentation violation detected at Tue Jun 23 15:25:36 2015
------------------------------------------------------------------------
Configuration:
Crash Decoding : Disabled
Default Encoding : UTF-8
GNU C Library : 2.19 stable
MATLAB Architecture: glnxa64
MATLAB Root : /usr/local/MATLAB/MATLAB_Compiler_Runtime/v81
MATLAB Version : 8.1.0.604 (R2013a)
Operating System : Linux 3.13.0-32-generic #57-Ubuntu SMP Tue
Jul 15 03:51:08 UTC 2014 x86_64
Processor ID : x86 Family 6 Model 60 Stepping 3,
A technical support engineer might contact you with further
information.
Thank you for your help.** This crash report has been saved to disk
as /home/gnuradio/matlab_crash_dump.16446-1 **
MATLAB is exiting because of fatal error
>>> Done???
"The stack trace strongly suggests that the crash is related to a
Boost library version conflict. MATLAB R2013a/MCR v8.1 includes and
depends on Boost 1.49 libraries. In the stack trace we see that in
practice your system's Boost 1.54 libraries are being accessed
however.
These things may occur if you load a MATLAB Compiler Shared Library
into an application which is already making use of this system Boost
library.
There are no quick/easy workarounds for such issues other than:
1. Making sure that all components involved make use of the same
Boost library versions, or
2. Making sure that the components which require Boost statically
link against the Boost version which they prefer, or
3. Separating the different components which require Boost into
separate applications.
In further detail:
Option 1: It looks like you are making use of GNU Radio from Python,
I do believe that GNU Radio depends on Boost. You may be able to
(re)compile GNU Radio to make it use Boost 1.49 and where you even
specifically link it to the Boost libraries shipped with the MCR
(these can be found in the bin/glnxa64 directory).
Option 2: If GNU Radio specifically requires a different Boost
version you may be able to recompile it and statically link it
against this version.
Option 3: Instead of compiling your MATLAB Code into a Shared
Library, compile it into a standalone application which you can
launch from your Python process. This separate standalone should be
able to use its own Boost libraries without problems then. There are
Python libraries which can read and write MAT-files so you can
relatively efficiently pass in- and outputs from and to that
standalone application through MAT-files."
------------------------------------------------------------------------
*From:*
discuss-gnuradio-bounces+david.halls=removed_email_address@domain.invalid
<discuss-gnuradio-bounces+david.halls=removed_email_address@domain.invalid> on
behalf of Marcus M??ller <[email protected]>
*Sent:* 14 August 2015 17:59
*To:* [email protected]
*Subject:* Re: [Discuss-gnuradio] Building GNU Radio with previous
Boost version
Hi David,
boost > 1.35 should work, but 1.49 is, if I remember correctly, an
especially buggy version, especially in Ubuntu.
I guess you wouldn't ask if there wasn't a problem, so maybe you
want to elaborate?
Best regards,
Marcus
On 08/14/2015 06:00 PM, David Halls wrote:
------------------------------------------------------------------------
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------------------------------------------------
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read,
copied and used only by the intended recipient. If you are not the
intended recipient, please destroy this message, delete any copies
held on your system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton
Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
------------------------------------------------------------------------
This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com
------------------------------------------------------------------------
I am not sure I totally understand what that entails, and I certainly am
not clear how to go about doing it!! Does it mean that GNU Radio would
use it’s “preferred” Boost via static linking leaving MATLAB to use a
different version - how would this run differently to the current setup,
and avoid conflict?
Thanks guys.
David
From: West, Nathan [email protected]
Sent: 17 August 2015 14:56
To: David Halls
Cc: Marcus Müller; [email protected]
Subject: Re: [Discuss-gnuradio] Building GNU Radio with previous Boost
version
There are no quick/easy workarounds for such issues other than:
Making sure that all components involved make use of the same Boost
library versions, or
Making sure that the components which require Boost statically link
against the Boost version which they prefer, or
Separating the different components which require Boost into separate
applications.
In further detail:
Option 1: It looks like you are making use of GNU Radio from Python, I
do believe that GNU Radio depends on Boost. You may be able to
(re)compile GNU Radio to make it use Boost 1.49 and where you even
specifically link it to the Boost libraries shipped with the MCR (these
can be found in the bin/glnxa64 directory).
Option 2: If GNU Radio specifically requires a different Boost version
you may be able to recompile it and statically link it against this
version.
Option 3: Instead of compiling your MATLAB Code into a Shared Library,
compile it into a standalone application which you can launch from your
Python process. This separate standalone should be able to use its own
Boost libraries without problems then. There are Python libraries which
can read and write MAT-files so you can relatively efficiently pass in-
and outputs from and to that standalone application through MAT-files."
This sounds like good advice. Option 2 sounds the most sane.
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
Thanks Marcus I have tried building GNU Radio with Boost 1.49 (that
required by MATLAB)
I’ve made a little progress, but it’s slow going. I got the header files
(not included with the MATLAB release) by downloading Boost 1.49, and
building it and installing it to a home directory (not /usr/…).
(so I am pointing to my header files for the INCLUDEDIR, and MATLABs
libraries for the LIBRARYDIR)
the output includes positive sounding things like
– Boost version: 1.49.0
– Found the following Boost libraries:
– filesystem
– system
– unit_test_framework
– program_options
but when I then try “make VERBOSE=1”, there seem to be problems linking
volk as pasted below. Can anyone help? Thanks!
David
make VERBOSE=1
/usr/bin/cmake -H/home/gnuradio/gnuradio_build/gnuradio
-B/home/gnuradio/gnuradio_build/gnuradio/build --check-build-system
CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start
/home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles
/home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build' make -f volk/lib/CMakeFiles/volk.dir/build.make volk/lib/CMakeFiles/volk.dir/depend make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build’
cd /home/gnuradio/gnuradio_build/gnuradio/build && /usr/bin/cmake -E
cmake_depends “Unix Makefiles” /home/gnuradio/gnuradio_build/gnuradio
/home/gnuradio/gnuradio_build/gnuradio/volk/lib
/home/gnuradio/gnuradio_build/gnuradio/build
/home/gnuradio/gnuradio_build/gnuradio/build/volk/lib
/home/gnuradio/gnuradio_build/gnuradio/build/volk/lib/CMakeFiles/volk.dir/DependInfo.cmake
–color=
make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build' make -f volk/lib/CMakeFiles/volk.dir/build.make volk/lib/CMakeFiles/volk.dir/build make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build’
make[2]: Nothing to be done for volk/lib/CMakeFiles/volk.dir/build'. make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build’
/usr/bin/cmake -E cmake_progress_report
/home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles 95 96 97 98 99
[ 5%] Built target volk
make -f volk/lib/CMakeFiles/test_all.dir/build.make
volk/lib/CMakeFiles/test_all.dir/depend
make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build' cd /home/gnuradio/gnuradio_build/gnuradio/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/gnuradio/gnuradio_build/gnuradio /home/gnuradio/gnuradio_build/gnuradio/volk/lib /home/gnuradio/gnuradio_build/gnuradio/build /home/gnuradio/gnuradio_build/gnuradio/build/volk/lib /home/gnuradio/gnuradio_build/gnuradio/build/volk/lib/CMakeFiles/test_all.dir/DependInfo.cmake --color= make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build’
make -f volk/lib/CMakeFiles/test_all.dir/build.make
volk/lib/CMakeFiles/test_all.dir/build
make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build' make[2]: Nothing to be done for volk/lib/CMakeFiles/test_all.dir/build’.
make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build' /usr/bin/cmake -E cmake_progress_report /home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles [ 5%] Built target test_all make -f volk/apps/CMakeFiles/volk-config-info.dir/build.make volk/apps/CMakeFiles/volk-config-info.dir/depend make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build’
cd /home/gnuradio/gnuradio_build/gnuradio/build && /usr/bin/cmake -E
cmake_depends “Unix Makefiles” /home/gnuradio/gnuradio_build/gnuradio
/home/gnuradio/gnuradio_build/gnuradio/volk/apps
/home/gnuradio/gnuradio_build/gnuradio/build
/home/gnuradio/gnuradio_build/gnuradio/build/volk/apps
/home/gnuradio/gnuradio_build/gnuradio/build/volk/apps/CMakeFiles/volk-config-info.dir/DependInfo.cmake
–color=
make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build' make -f volk/apps/CMakeFiles/volk-config-info.dir/build.make volk/apps/CMakeFiles/volk-config-info.dir/build make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build’
make[2]: Nothing to be done for volk/apps/CMakeFiles/volk-config-info.dir/build'. make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build’
/usr/bin/cmake -E cmake_progress_report
/home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles
[ 5%] Built target volk-config-info
make -f volk/apps/CMakeFiles/volk_profile.dir/build.make
volk/apps/CMakeFiles/volk_profile.dir/depend
make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build' cd /home/gnuradio/gnuradio_build/gnuradio/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/gnuradio/gnuradio_build/gnuradio /home/gnuradio/gnuradio_build/gnuradio/volk/apps /home/gnuradio/gnuradio_build/gnuradio/build /home/gnuradio/gnuradio_build/gnuradio/build/volk/apps /home/gnuradio/gnuradio_build/gnuradio/build/volk/apps/CMakeFiles/volk_profile.dir/DependInfo.cmake --color= make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build’
make -f volk/apps/CMakeFiles/volk_profile.dir/build.make
volk/apps/CMakeFiles/volk_profile.dir/build
make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build' Linking CXX executable volk_profile cd /home/gnuradio/gnuradio_build/gnuradio/build/volk/apps && /usr/bin/cmake -E cmake_link_script CMakeFiles/volk_profile.dir/link.txt --verbose=1 /usr/bin/c++ -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -O3 -DNDEBUG CMakeFiles/volk_profile.dir/volk_profile.cc.o CMakeFiles/volk_profile.dir/__/lib/qa_utils.cc.o -o volk_profile -rdynamic ../lib/libvolk.so.0.0.0 -lboost_filesystem -lboost_system -lboost_unit_test_framework -lboost_program_options -ldl -lorc-0.4 -Wl,-rpath,/home/gnuradio/gnuradio_build/gnuradio/build/volk/lib: CMakeFiles/volk_profile.dir/volk_profile.cc.o: In function main’:
volk_profile.cc:(.text.startup+0x613b): undefined reference to boost::filesystem3::path::wchar_t_codecvt_facet()' volk_profile.cc:(.text.startup+0x6193): undefined reference to boost::filesystem3::path::parent_path() const’
volk_profile.cc:(.text.startup+0x61a2): undefined reference to boost::filesystem3::detail::status(boost::filesystem3::path const&, boost::system::error_code*)' volk_profile.cc:(.text.startup+0x65b1): undefined reference to boost::filesystem3::path::parent_path() const’
volk_profile.cc:(.text.startup+0x6613): undefined reference to boost::filesystem3::path::parent_path() const' volk_profile.cc:(.text.startup+0x6622): undefined reference to boost::filesystem3::detail::create_directories(boost::filesystem3::path
const&, boost::system::error_code*)’
collect2: error: ld returned 1 exit status
make[2]: *** [volk/apps/volk_profile] Error 1
make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build' make[1]: *** [volk/apps/CMakeFiles/volk_profile.dir/all] Error 2 make[1]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build’
make: *** [all] Error 2
From: Marcus Müller [email protected]
Sent: 17 August 2015 15:22
To: David Halls; [email protected]
Subject: RE: [Discuss-gnuradio] Building GNU Radio with previous Boost
version
Hi David,
I think we can all agree that the community starting to run at the
mention of Matlab is not a good thing - I think there might be
frustration behind this flight instinct, so let’s try to make this a
success story.
I concur with the pretty detailed reply from mathworks; the reason is
likely to be the binary/abi mismatch between the boost GNU Radio/your
native runtime linker uses and the one that the Matlab library needs.
Now, you should be able to specify the boost that cmake uses when
configuring the build process:
cmake -DBOOST_INCLUDEDIR=
-DBOOST_LIBRARY_DIR= …
Also make sure to specify export LD_LIBRARY_DIR containing the same
matlab library dir; otherwise, at runtime your system’s boost will get
linked in, and that will still result in segfaults.
Maybe there is also the option to statically link the Matlab library
before loading it from GNU Radio, instead of doing it the other way
around (which is option 2). To me, that sounds more logically sound,
since it’s Matlab that introduces library dependencies that are
incompatible with your system libraries, because otherwise you might run
into the same problem for other libraries that both Mathworks code and
GNU Radio use and Mathworks ships their own version with. However, I
don’t know if that would even be possible, as I don’t have Matlab around
to test it.
All in all, I also like option 3 from Mathwork’s reply, though I don’t
think the .mat method would work well for streaming like GNU Radio does;
you should be able to just open a file (fopen) and read from it (fread)
in a loop, so that you can get what a file source in GNU Radio writes to
a FIFO; basically, as Matlab pseudocode:
first and then use file sink/source to write/read to/from these.
Of course, a socket- or IPC-based solution might be cleaner, but I don’t
know much popular matlab tools that make it easy to write “real-world
compatible” Matlab code (I think that lack of knowledge of high-quality
well-known libraries might be what leads people to run away as soon as
you mention Matlab).
I am calling MATLAB compiled code from within GNURadio C++ blocks.
MATLAB compiled code uses a specific version of Boost, and they are
still using 1.49, even with their latest release. I get a the trace
below when I try to run the MATLAB code on newer GNURadio/Ubuntu/Boost
though it works fine on my old (ancient) GNURadio/Ubuntu/Boost build
where the Boost versions match. (Also included is MathWorks take on it).
I was reticent to give all the details because previous MATLAB questions
have left the community running for the hills, saying I should write
everything directly in C++ etc, but there are lots of reasons we can’t
do this, for now!
Thanks,
David
(python2:16446): IBUS-WARNING **: The owner of
/home/gnuradio/.config/ibus/bus is not root!
Using Volk machine: avx_64_mmx_orc
Attempting to initialise the MCR application…
Attempting to initialise the libdla application…
Segmentation violation detected at Tue Jun 23 15:25:36 2015
Configuration:
Crash Decoding : Disabled
Default Encoding : UTF-8
GNU C Library : 2.19 stable
MATLAB Architecture: glnxa64
MATLAB Root : /usr/local/MATLAB/MATLAB_Compiler_Runtime/v81
MATLAB Version : 8.1.0.604 (R2013a)
Operating System : Linux 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15
03:51:08 UTC 2014 x86_64
Processor ID : x86 Family 6 Model 60 Stepping 3, GenuineIntel
A technical support engineer might contact you with further information.
Thank you for your help.** This crash report has been saved to disk as
/home/gnuradio/matlab_crash_dump.16446-1 **
MATLAB is exiting because of fatal error
Done
"The stack trace strongly suggests that the crash is related to a Boost
library version conflict. MATLAB R2013a/MCR v8.1 includes and depends on
Boost 1.49 libraries. In the stack trace we see that in practice your
system’s Boost 1.54 libraries are being accessed however.
These things may occur if you load a MATLAB Compiler Shared Library into
an application which is already making use of this system Boost library.
There are no quick/easy workarounds for such issues other than:
Making sure that all components involved make use of the same Boost
library versions, or
Making sure that the components which require Boost statically link
against the Boost version which they prefer, or
Separating the different components which require Boost into separate
applications.
In further detail:
Option 1: It looks like you are making use of GNU Radio from Python, I
do believe that GNU Radio depends on Boost. You may be able to
(re)compile GNU Radio to make it use Boost 1.49 and where you even
specifically link it to the Boost libraries shipped with the MCR (these
can be found in the bin/glnxa64 directory).
Option 2: If GNU Radio specifically requires a different Boost version
you may be able to recompile it and statically link it against this
version.
Option 3: Instead of compiling your MATLAB Code into a Shared Library,
compile it into a standalone application which you can launch from your
Python process. This separate standalone should be able to use its own
Boost libraries without problems then. There are Python libraries which
can read and write MAT-files so you can relatively efficiently pass in-
and outputs from and to that standalone application through MAT-files."
boost > 1.35 should work, but 1.49 is, if I remember correctly, an
especially buggy version, especially in Ubuntu.
I guess you wouldn’t ask if there wasn’t a problem, so maybe you want to
elaborate?
Best regards,
Marcus
On 08/14/2015 06:00 PM, David Halls wrote:
Hi guys,
For a number of complicated reasons I would like to build GNU Radio with
an older version of Boost. Specifically 1.49.
Thanks,
David
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web:
www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl
This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web:
www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl
This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
this involves find and replace of TIME_UTC with TIME_UTC_ in a number of
files. Just do a find and replace in all of the source code, they are
all shown in
Finally at run-time one must point to the 1.49 libraries when launching
GRC. I achieved this by adding the library path to /etc/ld.so.conf, but
others may correct me and suggest a more suitable location for that
change.
Thanks all for the help.
David
p.s. I will go on to create full documentation about how to call MATLAB
shared libraries from GNU Radio, now the boost conflict has been
resolved…
From: David Halls
Sent: 19 August 2015 17:48
To: Marcus Müller; [email protected]
Subject: RE: [Discuss-gnuradio] Building GNU Radio with previous Boost
version
Marcus, Nathan, All,
Thanks Marcus I have tried building GNU Radio with Boost 1.49 (that
required by MATLAB)
I’ve made a little progress, but it’s slow going. I got the header files
(not included with the MATLAB release) by downloading Boost 1.49, and
building it and installing it to a home directory (not /usr/…).
(so I am pointing to my header files for the INCLUDEDIR, and MATLABs
libraries for the LIBRARYDIR)
the output includes positive sounding things like
– Boost version: 1.49.0
– Found the following Boost libraries:
– filesystem
– system
– unit_test_framework
– program_options
but when I then try “make VERBOSE=1”, there seem to be problems linking
volk as pasted below. Can anyone help? Thanks!
David
make VERBOSE=1
/usr/bin/cmake -H/home/gnuradio/gnuradio_build/gnuradio
-B/home/gnuradio/gnuradio_build/gnuradio/build --check-build-system
CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start
/home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles
/home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build' make -f volk/lib/CMakeFiles/volk.dir/build.make volk/lib/CMakeFiles/volk.dir/depend make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build’
cd /home/gnuradio/gnuradio_build/gnuradio/build && /usr/bin/cmake -E
cmake_depends “Unix Makefiles” /home/gnuradio/gnuradio_build/gnuradio
/home/gnuradio/gnuradio_build/gnuradio/volk/lib
/home/gnuradio/gnuradio_build/gnuradio/build
/home/gnuradio/gnuradio_build/gnuradio/build/volk/lib
/home/gnuradio/gnuradio_build/gnuradio/build/volk/lib/CMakeFiles/volk.dir/DependInfo.cmake
–color=
make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build' make -f volk/lib/CMakeFiles/volk.dir/build.make volk/lib/CMakeFiles/volk.dir/build make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build’
make[2]: Nothing to be done for volk/lib/CMakeFiles/volk.dir/build'. make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build’
/usr/bin/cmake -E cmake_progress_report
/home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles 95 96 97 98 99
[ 5%] Built target volk
make -f volk/lib/CMakeFiles/test_all.dir/build.make
volk/lib/CMakeFiles/test_all.dir/depend
make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build' cd /home/gnuradio/gnuradio_build/gnuradio/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/gnuradio/gnuradio_build/gnuradio /home/gnuradio/gnuradio_build/gnuradio/volk/lib /home/gnuradio/gnuradio_build/gnuradio/build /home/gnuradio/gnuradio_build/gnuradio/build/volk/lib /home/gnuradio/gnuradio_build/gnuradio/build/volk/lib/CMakeFiles/test_all.dir/DependInfo.cmake --color= make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build’
make -f volk/lib/CMakeFiles/test_all.dir/build.make
volk/lib/CMakeFiles/test_all.dir/build
make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build' make[2]: Nothing to be done for volk/lib/CMakeFiles/test_all.dir/build’.
make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build' /usr/bin/cmake -E cmake_progress_report /home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles [ 5%] Built target test_all make -f volk/apps/CMakeFiles/volk-config-info.dir/build.make volk/apps/CMakeFiles/volk-config-info.dir/depend make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build’
cd /home/gnuradio/gnuradio_build/gnuradio/build && /usr/bin/cmake -E
cmake_depends “Unix Makefiles” /home/gnuradio/gnuradio_build/gnuradio
/home/gnuradio/gnuradio_build/gnuradio/volk/apps
/home/gnuradio/gnuradio_build/gnuradio/build
/home/gnuradio/gnuradio_build/gnuradio/build/volk/apps
/home/gnuradio/gnuradio_build/gnuradio/build/volk/apps/CMakeFiles/volk-config-info.dir/DependInfo.cmake
–color=
make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build' make -f volk/apps/CMakeFiles/volk-config-info.dir/build.make volk/apps/CMakeFiles/volk-config-info.dir/build make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build’
make[2]: Nothing to be done for volk/apps/CMakeFiles/volk-config-info.dir/build'. make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build’
/usr/bin/cmake -E cmake_progress_report
/home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles
[ 5%] Built target volk-config-info
make -f volk/apps/CMakeFiles/volk_profile.dir/build.make
volk/apps/CMakeFiles/volk_profile.dir/depend
make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build' cd /home/gnuradio/gnuradio_build/gnuradio/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/gnuradio/gnuradio_build/gnuradio /home/gnuradio/gnuradio_build/gnuradio/volk/apps /home/gnuradio/gnuradio_build/gnuradio/build /home/gnuradio/gnuradio_build/gnuradio/build/volk/apps /home/gnuradio/gnuradio_build/gnuradio/build/volk/apps/CMakeFiles/volk_profile.dir/DependInfo.cmake --color= make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build’
make -f volk/apps/CMakeFiles/volk_profile.dir/build.make
volk/apps/CMakeFiles/volk_profile.dir/build
make[2]: Entering directory /home/gnuradio/gnuradio_build/gnuradio/build' Linking CXX executable volk_profile cd /home/gnuradio/gnuradio_build/gnuradio/build/volk/apps && /usr/bin/cmake -E cmake_link_script CMakeFiles/volk_profile.dir/link.txt --verbose=1 /usr/bin/c++ -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -O3 -DNDEBUG CMakeFiles/volk_profile.dir/volk_profile.cc.o CMakeFiles/volk_profile.dir/__/lib/qa_utils.cc.o -o volk_profile -rdynamic ../lib/libvolk.so.0.0.0 -lboost_filesystem -lboost_system -lboost_unit_test_framework -lboost_program_options -ldl -lorc-0.4 -Wl,-rpath,/home/gnuradio/gnuradio_build/gnuradio/build/volk/lib: CMakeFiles/volk_profile.dir/volk_profile.cc.o: In function main’:
volk_profile.cc:(.text.startup+0x613b): undefined reference to boost::filesystem3::path::wchar_t_codecvt_facet()' volk_profile.cc:(.text.startup+0x6193): undefined reference to boost::filesystem3::path::parent_path() const’
volk_profile.cc:(.text.startup+0x61a2): undefined reference to boost::filesystem3::detail::status(boost::filesystem3::path const&, boost::system::error_code*)' volk_profile.cc:(.text.startup+0x65b1): undefined reference to boost::filesystem3::path::parent_path() const’
volk_profile.cc:(.text.startup+0x6613): undefined reference to boost::filesystem3::path::parent_path() const' volk_profile.cc:(.text.startup+0x6622): undefined reference to boost::filesystem3::detail::create_directories(boost::filesystem3::path
const&, boost::system::error_code*)’
collect2: error: ld returned 1 exit status
make[2]: *** [volk/apps/volk_profile] Error 1
make[2]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build' make[1]: *** [volk/apps/CMakeFiles/volk_profile.dir/all] Error 2 make[1]: Leaving directory /home/gnuradio/gnuradio_build/gnuradio/build’
make: *** [all] Error 2
From: Marcus Müller [email protected]
Sent: 17 August 2015 15:22
To: David Halls; [email protected]
Subject: RE: [Discuss-gnuradio] Building GNU Radio with previous Boost
version
Hi David,
I think we can all agree that the community starting to run at the
mention of Matlab is not a good thing - I think there might be
frustration behind this flight instinct, so let’s try to make this a
success story.
I concur with the pretty detailed reply from mathworks; the reason is
likely to be the binary/abi mismatch between the boost GNU Radio/your
native runtime linker uses and the one that the Matlab library needs.
Now, you should be able to specify the boost that cmake uses when
configuring the build process:
cmake -DBOOST_INCLUDEDIR=
-DBOOST_LIBRARY_DIR= …
Also make sure to specify export LD_LIBRARY_DIR containing the same
matlab library dir; otherwise, at runtime your system’s boost will get
linked in, and that will still result in segfaults.
Maybe there is also the option to statically link the Matlab library
before loading it from GNU Radio, instead of doing it the other way
around (which is option 2). To me, that sounds more logically sound,
since it’s Matlab that introduces library dependencies that are
incompatible with your system libraries, because otherwise you might run
into the same problem for other libraries that both Mathworks code and
GNU Radio use and Mathworks ships their own version with. However, I
don’t know if that would even be possible, as I don’t have Matlab around
to test it.
All in all, I also like option 3 from Mathwork’s reply, though I don’t
think the .mat method would work well for streaming like GNU Radio does;
you should be able to just open a file (fopen) and read from it (fread)
in a loop, so that you can get what a file source in GNU Radio writes to
a FIFO; basically, as Matlab pseudocode:
first and then use file sink/source to write/read to/from these.
Of course, a socket- or IPC-based solution might be cleaner, but I don’t
know much popular matlab tools that make it easy to write “real-world
compatible” Matlab code (I think that lack of knowledge of high-quality
well-known libraries might be what leads people to run away as soon as
you mention Matlab).
I am calling MATLAB compiled code from within GNURadio C++ blocks.
MATLAB compiled code uses a specific version of Boost, and they are
still using 1.49, even with their latest release. I get a the trace
below when I try to run the MATLAB code on newer GNURadio/Ubuntu/Boost
though it works fine on my old (ancient) GNURadio/Ubuntu/Boost build
where the Boost versions match. (Also included is MathWorks take on it).
I was reticent to give all the details because previous MATLAB questions
have left the community running for the hills, saying I should write
everything directly in C++ etc, but there are lots of reasons we can’t
do this, for now!
Thanks,
David
(python2:16446): IBUS-WARNING **: The owner of
/home/gnuradio/.config/ibus/bus is not root!
Using Volk machine: avx_64_mmx_orc
Attempting to initialise the MCR application…
Attempting to initialise the libdla application…
Segmentation violation detected at Tue Jun 23 15:25:36 2015
Configuration:
Crash Decoding : Disabled
Default Encoding : UTF-8
GNU C Library : 2.19 stable
MATLAB Architecture: glnxa64
MATLAB Root : /usr/local/MATLAB/MATLAB_Compiler_Runtime/v81
MATLAB Version : 8.1.0.604 (R2013a)
Operating System : Linux 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15
03:51:08 UTC 2014 x86_64
Processor ID : x86 Family 6 Model 60 Stepping 3, GenuineIntel
A technical support engineer might contact you with further information.
Thank you for your help.** This crash report has been saved to disk as
/home/gnuradio/matlab_crash_dump.16446-1 **
MATLAB is exiting because of fatal error
Done
"The stack trace strongly suggests that the crash is related to a Boost
library version conflict. MATLAB R2013a/MCR v8.1 includes and depends on
Boost 1.49 libraries. In the stack trace we see that in practice your
system’s Boost 1.54 libraries are being accessed however.
These things may occur if you load a MATLAB Compiler Shared Library into
an application which is already making use of this system Boost library.
There are no quick/easy workarounds for such issues other than:
Making sure that all components involved make use of the same Boost
library versions, or
Making sure that the components which require Boost statically link
against the Boost version which they prefer, or
Separating the different components which require Boost into separate
applications.
In further detail:
Option 1: It looks like you are making use of GNU Radio from Python, I
do believe that GNU Radio depends on Boost. You may be able to
(re)compile GNU Radio to make it use Boost 1.49 and where you even
specifically link it to the Boost libraries shipped with the MCR (these
can be found in the bin/glnxa64 directory).
Option 2: If GNU Radio specifically requires a different Boost version
you may be able to recompile it and statically link it against this
version.
Option 3: Instead of compiling your MATLAB Code into a Shared Library,
compile it into a standalone application which you can launch from your
Python process. This separate standalone should be able to use its own
Boost libraries without problems then. There are Python libraries which
can read and write MAT-files so you can relatively efficiently pass in-
and outputs from and to that standalone application through MAT-files."
boost > 1.35 should work, but 1.49 is, if I remember correctly, an
especially buggy version, especially in Ubuntu.
I guess you wouldn’t ask if there wasn’t a problem, so maybe you want to
elaborate?
Best regards,
Marcus
On 08/14/2015 06:00 PM, David Halls wrote:
Hi guys,
For a number of complicated reasons I would like to build GNU Radio with
an older version of Boost. Specifically 1.49.
Thanks,
David
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web:
www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl
This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web:
www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl
This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.