Thanks Andrew. I actually am doing an RFNoC cross-compile, so the best of both painful worlds. I noticed that I was referencing the folder e300 in some of my commands and E310 in others, so that was a big problem. I blew away both of those directories and started over fresh to make sure I wouldn't have those issues anymore. I also noticed that if I ran cmake-gui, gnuradio wasn't pointing to the newly build UHD, but was pointing to the one in the cross-compile. I added the CMAKE command flags mentioned in one of the knowledge-bases and now it points to the proper location for UHD libraries. Sadly, I can't get past the GR build now due to weird errors that seem to have something to do with the cross-compile and recent commits. If I work off of the head, I get errors with the gnuradio-runtime/lib/single_threaded_scheduler.cc file complaining about an "overload*" operator. If I start stepping back, I start to get them time_spec errors. Scanning dependencies of target _uhd_swig [ 56%] Building CXX object gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o /opt/gnuradio/e300/src/gnuradio/build-arm/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In function 'PyObject* _wrap_time_spec_t_get_system_time(PyObject*, PyObject*)': /opt/gnuradio/e300/src/gnuradio/build-arm/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:20502:34: error: 'get_system_time' is not a member of 'uhd::time_spec_t' result = uhd::time_spec_t::get_system_time(); It feels like I need to use the head of GR, but that something in the cross-compile isn't playing nice with the single_threaded_scheduler.cc operator overload. It's never easy... --------- Original Message --------- Subject: Re: [USRP-users] E310 cross-compile issue From: "Andrew Danowitz" <and...@whitefoxdefense.com> Date: 9/10/18 12:35 pm To: "Jason Matusiak" <ja...@gardettoengineering.com> Cc: "Ettus Mail List" <usrp-users@lists.ettus.com>
I've never gotten this error on a cross-compile build, but I have gotten it on an rfnoc build. In my case, the linker was finding headers from a system install of gnuradio and trying to use those instead of the fresh ones generated by make. I might uninstall any repository installs of gnuradio or temporarily muck with some environment variables so make only finds your local, up-to-date header files. On Mon, Sep 10, 2018 at 4:51 AM, Jason Matusiak via USRP-users <usrp-users@lists.ettus.com> wrote: OK, I am having a weird cross-compile issue still. I am using the latest cross-compile files from Philip, but I am getting a weird error that has me stumped. Here are the steps I took, maybe I hosed something up along the way. I am worried about: 1 - How I setup the cmakes 2 - enabling RFNOC properly 3 - that I have proper versions of things (I went and rolled back gnuradio to v3.7.12.0 due to it having error, maybe I need to do that for gr-ettus as well?) Here were my steps followed by the error at the end: 997 mkdir /opt/gnuradio/E310 998 sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0.sh 999 cd /opt/gnuradio/E310/ 1004 unset LD_LIBRARY_PATH 1005 source ./environment-setup-armv7ahf-neon-oe-linux-gnueabi 1006 echo $CC 1007 mkdir src 1008 cd src/ 1009 git clone https://github.com/EttusResearch/uhd.git 1010 cd uhd/host && mkdir build && cd build 1011 cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON -DENABLE_RFNOC=ON .. 1013 make -j8 1014 make install DESTDIR=/opt/gnuradio/E310 1015 cd ../../ 1016 cd .. 1018 git clone --recursive https://github.com/gnuradio/gnuradio.git 1020 cd gnuradio/ 1026 git checkout v3.7.12.0 1027 mkdir build 1028 cd build/ 1029 cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/oe-sdk_cross.cmake -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_GR_VOCODER=OFF -DENABLE_GR_ATSC=OFF -DENABLE_GR_DTV=OFF -DENABLE_DOXYGEN=OFF ../ 1030 make -j8 1031 make -j4 install DESTDIR=/opt/gnuradio/E310 1032 cd ../../ 1034 git clone https://github.com/EttusResearch/gr-ettus.git 1035 cd gr-ettus/ 1037 mkdir build 1038 cd build && cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../../uhd/host/cmake/Toolchains/oe-sdk_cross.cmake -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_DOXYGEN=OFF -DUHD_DIR=/opt/gnuradio/e300/usr/lib/cmake/uhd -DUHD_INCLUDE_DIRS=/opt/gnuradio/e300/usr/include -DUHD_LIBRARIES=/opt/gnuradio/e300/usr/lib ../ 1039 make -j4 And then I get the build error for gr-ettus: [ 90%] Building CXX object swig/CMakeFiles/_ettus_swig.dir/ettus_swigPYTHON_wrap.cxx.o [ 92%] Linking CXX executable test-ettus [ 92%] Built target test-ettus /opt/gnuradio/E310/src/gr-ettus/build/swig/ettus_swigPYTHON_wrap.cxx: In function 'PyObject* _wrap_time_spec_t_get_system_time(PyObject*, PyObject*)': /opt/gnuradio/E310/src/gr-ettus/build/swig/ettus_swigPYTHON_wrap.cxx:18100:34: error: 'get_system_time' is not a member of 'uhd::time_spec_t' result = uhd::time_spec_t::get_system_time(); ^~~~~~~~~~~~~~~ make[2]: *** [swig/CMakeFiles/_ettus_swig.dir/ettus_swigPYTHON_wrap.cxx.o] Error 1 make[1]: *** [swig/CMakeFiles/_ettus_swig.dir/all] Error 2 make: *** [all] Error 2 Philip thought that maybe I was using too old of a version of UHD, but I am using the head (hash 6013a), as well as the head of gr-ettus (hash 4ef12). It seems like there is a mismatch somewhere, but I am not sure how to resolve this. Could there be a problem with the cross-compile tools not being able to build things? _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com Information contained, linked, or attached to this email and all verbal communications from WhiteFox Defense to your entity in the prior 30 days constitute proprietary and confidential information unless otherwise indicated and is therefore subject to obligations in any executed confidentiality agreements. Further, this email is intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient and this message has been addressed to you in error, please promptly notify i...@whitefoxdefense.com and destroy all copies of the message and any attachments. This email and attachments may contain technical data as defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 - 780. Export of this material may be controlled by these regulations and may not be exported or transferred to non-U.S. persons without prior written approval from the U.S. government.
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
