discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Build GR 3.8 from source


From: Michael Dickens
Subject: Re: [Discuss-gnuradio] Build GR 3.8 from source
Date: Sun, 21 Jul 2019 13:41:52 -0400
User-agent: Cyrus-JMAP/3.1.6-736-gdfb8e44-fmstable-20190718v2

Hi Barry - OK; good progress! Can you do the following, from the top-level 
"build" directory (looks like "/home/pi/gnuradio/build"):
{{{
make clean
make VERBOSE=ON 2>&1 | tee make_out.txt
}}}
and then walk away & let it go until it's done. You'll be able to see the build 
going along via the 'tee' command. Please be patient! It might work; it might 
not! Either way on an RPi it'll take some time to build whatever it can! - MLD

On Sun, Jul 21, 2019, at 9:42 AM, Barry Duggan wrote:
> Hi Michael,
> 
> 'sudo pip3 install click-plugins' took care of the problem with cmake. 
> Then 'make' started OK, but when it got to 13%, it just hung in a tight 
> loop. After about an hour of waiting, I did a control-C and it finally 
> recognized it. I repeated the 'make' and it stopped in the same place. 
> See the following...
> 
> [ 13%] Building CXX object 
> gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx.o
> /home/pi/gnuradio/build/gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx:
>  
> In function ‘void SWIG_Python_addvarlink(PyObject*, char*, PyObject* 
> (*)(), int (*)(PyObject*))’:
> /home/pi/gnuradio/build/gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx:73109:16:
>  
> warning: ‘char* strncpy(char*, const char*, size_t)’ specified bound 
> depends on the length of the source argument [-Wstringop-overflow=]
>           strncpy(gv->name,name,size);
>           ~~~~~~~^~~~~~~~~~~~~~~~~~~~
> /home/pi/gnuradio/build/gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx:73106:27:
>  
> note: length computed here
>         size_t size = strlen(name)+1;
>                       ~~~~~~^~~~~~
> In file included from /usr/include/c++/8/vector:69,
>                   from 
> /home/pi/gnuradio/build/gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx:3060:
> /usr/include/c++/8/bits/vector.tcc: In function ‘void std::vector<_Tp, 
> _Alloc>::_M_range_insert(std::vector<_Tp, _Alloc>::iterator, 
> _ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with 
> _ForwardIterator = __gnu_cxx::__normal_iterator<const 
> std::complex<double>*, std::vector<std::complex<double>, 
> std::allocator<std::complex<double> > > >; _Tp = std::complex<double>; 
> _Alloc = std::allocator<std::complex<double> >]’:
> /usr/include/c++/8/bits/vector.tcc:672:7: note: parameter passing for 
> argument of type ‘std::vector<std::complex<double>, 
> std::allocator<std::complex<double> > >::iterator’ {aka 
> ‘__gnu_cxx::__normal_iterator<std::complex<double>*, 
> std::vector<std::complex<double>, std::allocator<std::complex<double> > 
>  > >’} changed in GCC 7.1
>         vector<_Tp, _Alloc>::
>         ^~~~~~~~~~~~~~~~~~~
> /usr/include/c++/8/bits/vector.tcc:672:7: note: parameter passing for 
> argument of type ‘__gnu_cxx::__normal_iterator<const 
> std::complex<double>*, std::vector<std::complex<double>, 
> std::allocator<std::complex<double> > > >’ changed in GCC 7.1
> /usr/include/c++/8/bits/vector.tcc:672:7: note: parameter passing for 
> argument of type ‘__gnu_cxx::__normal_iterator<const 
> std::complex<double>*, std::vector<std::complex<double>, 
> std::allocator<std::complex<double> > > >’ changed in GCC 7.1
> ^Cmake[2]: *** 
> [gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/build.make:63: 
> gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/CMakeFiles/runtime_swig.dir/runtime_swigPYTHON_wrap.cxx.o]
>  
> Interrupt
> make[1]: *** [CMakeFiles/Makefile2:1497: 
> gnuradio-runtime/swig/CMakeFiles/runtime_swig.dir/all] Interrupt
> make: *** [Makefile:141: all] Interrupt
> 
> I checked the memory space with 'df' and still have over 25GB available, 
> so that shouldn't be a problem.
> 
> What do you suggest?
> 
> Thanks,
> ---
> Barry Duggan



reply via email to

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