On 12/6/20 10:03 AM, Ron Economos via USRP-users wrote: > Unfortunately, that FFTW bug has been around for a while. Issue 213 is a > duplicate of issue 182 from a year+ ago. > > https://github.com/FFTW/fftw3/issues/182 > > On Ubuntu 20.04 armhf, they're just compiling the FFTW package without > NEON enabled.
I poked at this way more than I should have and am 99% certain the issue in in gcc-8. Building with -O off led to an fftw that would pass its make check. I tried a build on a qemuarm from OE/master and that worked (gcc-10). gcc-9 is a question, I fired up a build of OE/dunfell (gcc-9) and will run the qemu check and see what happens. If you are stuck on zeus, you'll need to try and id the patch that fixes gcc and apply it to the gcc build. But getting off zeus would be a really bood move as it is out of support now. Philip > > Ron > > On 12/6/20 06:27, Ben Magistro via USRP-users wrote: >> Issue appears to be with the compiler that is included in Zeus (gcc >> 9.x vs 8.x) and an interaction with fftw. There is an open issue with >> fftw (https://github.com/FFTW/fftw3/issues/213) and a request to the >> yocto folks to request they consider adding back gcc-8.3 to zeus + >> dunfell (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14144) >> until this can be better resolved. I think data point 3 confirms this >> as I did not include options to enable neon when I compiled. >> >> On Wed, Nov 11, 2020 at 1:39 PM Ben Magistro <konce...@gmail.com >> <mailto:konce...@gmail.com>> wrote: >> >> Adding some more data points. >> >> 1) I've been trying to rebuild meta-ettus-v4 with debug enabled >> but am hitting an issue with image size and can't seem to get past >> that. It says I should increase `MENDER_STORAGE_TOTAL_SIZE_MB` if >> the actual size is larger but increasing this seems to have no >> effect. I am using the ettus docker image for oe-builder with the >> command `./meta-ettus/contrib/build_imgs_package.sh e310_sg3 >> v4.0.0.0`. For the debug portion I've added a few lines to >> `build/conf/local.conf` to add the packages. I'm open to >> suggestions to build the image with debug symbols and provide >> additional feedback. >> >> 2) I put together a simple flowgraph, UHD source --> frequency >> xlating fft --> null sink. This also segfaults, no guarantees >> that I got the parameters correct. >> >> 3) Since the issues seem to be with fftw, I decided to try >> building my own copy of fftw mostly to get debug symbols and >> continue troubleshooting. For this I used `./configure >> --enable-debug --enable-shared --enable-threads --enable-float` >> and `make CFLAGS="-ggdb"`. These options are best guesses right >> now since I didn't look at the layers to see what parameters it is >> using (assuming it is in one of the layers). Using this build >> with `export LD_LIBRARY_PATH=/usr/local/lib/` I do not get a >> segfault with gr-ais or the above flowgraph but I also don't get >> the expected output which makes me question the parameters I used >> to build it. Output wise I get a string of "D" or "O" to the >> console. >> >> Thanks >> >> Ben >> >> On Thu, Nov 5, 2020 at 9:22 AM Michael Dickens >> <michael.dick...@ettus.com <mailto:michael.dick...@ettus.com>> wrote: >> >> Hi Ben - This issue has been reported to R&D internally. If >> you wish to create a public-facing UHD issue on our Github >> tracker please go ahead & do so, and tag me on it so that we >> can keep track of it internally. - MLD >> >> On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users >> <usrp-users@lists.ettus.com >> <mailto:usrp-users@lists.ettus.com>> wrote: >> >> Is anyone else using meta-ettus-v4.0.0.0 yet? if so, have >> you had any issues with libfftw? >> >> Using the image on an E310, adding a single OOT module >> (gr-ais) and trying to run an app distributed with it, the >> app segfaults. To further troubleshoot, I added gdb and >> it comes back with the following. I have a separate >> development host that has gnuradio 3.8 setup using pybombs >> and do not experience this issue there. >> >> Thread 1 "python3" received signal SIGSEGV, Segmentation >> fault. >> 0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3 >> >> To compile, I've needed to override PYTHON_EXECUTABLE as >> it points to a non-existent path in /home/oe-builder.... >> in /usr/lib/cmake/gnuradio/GnuradioConfig.cmake. To run I >> also needed to define LD_EXPORT_PATH pointing to >> /usr/local/lib/. >> >> Thanks in advance. >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> <mailto:USRP-users@lists.ettus.com> >> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
