Trouble building gnuradio/next (Linux Mint 14/64)

Greetings,

I tried to build the current gnuradio/next (v3.6.4.1-946-g7f0d3777) on
Linux Mint 14 64 bit today and it fails with one of those “never
ending” error messages: http://pastebin.com/7pBSB0h
At the same time, it build fine on Linux Mint 13 also 64 bit).
Both distributions have the same Ice version 3.4.2, but different gcc
and cmake (gcc 4.6.3 / cmake 2.8.7 versus gcc 4.7.2 / cmake 2.8.9).
The distributions should correspond to Ubuntu 12.04 and 12.10
respectively.

Anybody else seen this or has any ideas what to try? I’m very
interested in helping to make it build again.

Alex

On Sat, Mar 23, 2013 at 1:22 PM, Alexandru C. [email protected]
wrote:

Anybody else seen this or has any ideas what to try? I’m very
interested in helping to make it build again.

The correct link is: http://pastebin.com/7pBSB0h0

Alex

On Sat, Mar 23, 2013 at 8:24 AM, Alexandru C. [email protected]
wrote:

Anybody else seen this or has any ideas what to try? I’m very
interested in helping to make it build again.

The correct link is: http://pastebin.com/7pBSB0h0

Alex

Can you try installing that latest GCC 4.6 version in Mint? There’s a
known bug with GCC 4.7 and ICE, but I don’t think those patches have
made it into the main distros, yet. At least, on Ubuntu 12.10, I’ve
had to go back to 4.6 to get ControlPort to build.

Still trying to decide the right course of action for this.

Tom

On Sat, Mar 23, 2013 at 2:59 PM, Tom R. [email protected] wrote:

The distributions should correspond to Ubuntu 12.04 and 12.10 respectively.
known bug with GCC 4.7 and ICE, but I don’t think those patches have
made it into the main distros, yet. At least, on Ubuntu 12.10, I’ve
had to go back to 4.6 to get ControlPort to build.

Tom,

Thanks for the info. Is there a right way to switch to gcc 4.6?
I installed gcc-4.6 and without doing anything, cmake seems to pick it
up, but now I run into a different error, which suggests I should have
done some configuration first.

Linking CXX executable atsci_viterbi_gen
CMakeFiles/atsci_viterbi_gen.dir/atsci_viterbi_gen.cc.o: In function
build_decode_structures(char*)': atsci_viterbi_gen.cc:(.text+0x619): undefined reference tostd::cerr’
atsci_viterbi_gen.cc:(.text+0x61e): undefined reference to
std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' atsci_viterbi_gen.cc:(.text+0x62e): undefined reference tostd::basic_ostream<char, std::char_traits >::operator<<(int)’
atsci_viterbi_gen.cc:(.text+0x63b): undefined reference to
std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' atsci_viterbi_gen.cc:(.text+0x646): undefined reference tostd::basic_ostream<char, std::char_traits >::operator<<(long)’
atsci_viterbi_gen.cc:(.text+0x653): undefined reference to
std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' atsci_viterbi_gen.cc:(.text+0x663): undefined reference tostd::basic_ostream<char, std::char_traits >::operator<<(int)’
CMakeFiles/atsci_viterbi_gen.dir/atsci_viterbi_gen.cc.o: In function
usage()': atsci_viterbi_gen.cc:(.text+0x8b3): undefined reference tostd::cerr’
atsci_viterbi_gen.cc:(.text+0x8b8): undefined reference to
std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' atsci_viterbi_gen.cc:(.text+0x8c2): undefined reference tostd::cerr’
atsci_viterbi_gen.cc:(.text+0x8c7): undefined reference to
std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' atsci_viterbi_gen.cc:(.text+0x8d1): undefined reference tostd::cerr’
atsci_viterbi_gen.cc:(.text+0x8d6): undefined reference to
std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' CMakeFiles/atsci_viterbi_gen.dir/atsci_viterbi_gen.cc.o: In function__static_initialization_and_destruction_0(int, int)’:
atsci_viterbi_gen.cc:(.text+0x97a): undefined reference to
std::ios_base::Init::Init()' atsci_viterbi_gen.cc:(.text+0x97f): undefined reference tostd::ios_base::Init::~Init()’
collect2: ld returned 1 exit status
make[2]: *** [gr-atsc/lib/atsci_viterbi_gen] Error 1
make[1]: *** [gr-atsc/lib/CMakeFiles/atsci_viterbi_gen.dir/all] Error 2
make: *** [all] Error 2
[email protected] ~/sdr/gnuradio/v3.6.4.1-946-g7f0d3777-next/build $

Hi Tom,

Disabling the ATSC component did it! You are right, I don’t need it.
Enjoy your vacation!

Alex

I have seen the very same with Kubuntu 12.10 64 bit a few weeks ago…

Ralph.

On Sat, Mar 23, 2013 at 10:48 AM, Alexandru C. [email protected]
wrote:

and cmake (gcc 4.6.3 / cmake 2.8.7 versus gcc 4.7.2 / cmake 2.8.9).
Can you try installing that latest GCC 4.6 version in Mint? There’s a
done some configuration first.
std::basic_ostream<char, std::char_traits<char> >::operator<<(int)' atsci_viterbi_gen.cc:(.text+0x663): undefined reference to <std::char_traits<char> >(std::basic_ostream<char, atsci_viterbi_gen.cc:(.text+0x97f): undefined reference tostd::ios_base::Init::~Init()’
collect2: ld returned 1 exit status
make[2]: *** [gr-atsc/lib/atsci_viterbi_gen] Error 1
make[1]: *** [gr-atsc/lib/CMakeFiles/atsci_viterbi_gen.dir/all] Error 2
make: *** [all] Error 2
[email protected] ~/sdr/gnuradio/v3.6.4.1-946-g7f0d3777-next/build $

That looks like we’re not including some of the right headers in some
gr-atsc files. Probably something that will need a bit more time to
debug, and I’m kind of on vacation this weekend…

But, for now, just disable gr-atsc (-DENABLE_GR_ATSC=False); I’m
assuming you aren’t using it?

Tom

Now I get into trouble with Kubuntu 12.04 32bit when building it:

36%] Built target _gnuradio_core_filter_swig_tag
Linking CXX shared module _gnuradio_core_filter.so
[ 36%] Built target _gnuradio_core_filter
[ 36%] Built target _gnuradio_core_general_swig_tag
[ 36%] Building CXX object gnuradio-
core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o
/home/ras/gnuradio/master/gnuradio-
core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6083:22: error:
redefinition of ‘struct swig::traits’
/home/ras/gnuradio/master/gnuradio-
core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5498:22: error:
previous definition of ‘struct swig::traits’
/home/ras/gnuradio/master/gnuradio-
core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6087:23: error:
redefinition of ‘struct swig::traits_asval’
/home/ras/gnuradio/master/gnuradio-
core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5502:23: error:
previous definition of ‘struct swig::traits_asval’
/home/ras/gnuradio/master/gnuradio-
core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6093:23: error:
redefinition of ‘struct swig::traits_from’
/home/ras/gnuradio/master/gnuradio-
core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5508:23: error:
previous definition of ‘struct swig::traits_from’
/home/ras/gnuradio/master/gnuradio-
core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6103:22: error:
redefinition of ‘struct swig::traits<std::vector >’
/home/ras/gnuradio/master/gnuradio-
core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5518:22: error:
previous definition of ‘struct swig::traits<std::vector >’
make[2]: *** [gnuradio-
core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o]
Error 1
make[1]: *** [gnuradio-
core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/all] Error 2
make: *** [all] Error 2
[email protected]:~/gnuradio/master$

On Wed, Mar 27, 2013 at 2:47 AM, Tom R. [email protected] wrote:

On Sat, Mar 23, 2013 at 2:01 PM, Ralph A. Schmid, dk5ras
[email protected] wrote:

I have seen the very same with Kubuntu 12.10 64 bit a few weeks ago…

Ralph.

I just pushed what should be a fix for this. It built on my VM of Mint 14.

Hi Tom,

Thanks for the update. Is the fix for the failing ATSC build or the gcc
4.7?

Alex

On Wed, Mar 27, 2013 at 8:46 AM, Ralph A. Schmid [email protected]
wrote:

redefinition of struct swig::traits
core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6093:23: error:
make[2]: *** [gnuradio-

core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o]

Error 1
make[1]: *** [gnuradio-
core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/all] Error 2
make: *** [all] Error 2
[email protected]:~/gnuradio/master$

Well, it builds fine for me on Mint 13 64 bit, but note that we are
talking about the “next” branch - the directory in your error message
suggests it’s the master branch.

Alex

On Sat, Mar 23, 2013 at 2:01 PM, Ralph A. Schmid, dk5ras
[email protected] wrote:

I have seen the very same with Kubuntu 12.10 64 bit a few weeks ago…

Ralph.

I just pushed what should be a fix for this. It built on my VM of Mint
14.

Tom

On Wed, Mar 27, 2013 at 3:46 AM, Ralph A. Schmid [email protected]
wrote:

redefinition of struct swig::traits
core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6093:23: error:
make[2]: *** [gnuradio-

core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o]

Error 1
make[1]: *** [gnuradio-
core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/all] Error 2
make: *** [all] Error 2
[email protected]:~/gnuradio/master$

Ralph,

Going to need more information. What git commit are you using? Are you
building from a clean build directory? Did you previously build next
in this directory and are now going back to master?

Tom

First attempt was just git pull / cd master / make, then I received some
error regarding access rights. Huh?! Then I tried git clean -d -x -f, it
did
not remove the folder, so I sudo-deleted the folder, mkdir master, cd
master, cmake …, make. The result I mailed to the list. When I went
back
two days earlier everything builds fine, after a git pull again it does
not
build, so I can assume my system so far should be OK.

The only “stranke thing” on my machine I am aware of is a minimum
gnuradio
3.4.2 installation that I need to operate OpenBTS. I need to uninstall
it to
build some osmocom stuff (gr-… and other).

Ralph.

Going to need more information. What git commit are you using? Are you
building from a clean build directory? Did you previously build next in
this
directory and are now going back to master?

Tom

On Tuesday, March 26, 2013 09:47:54 PM you wrote:

I just pushed what should be a fix for this. It built on my VM of Mint


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

On Wed, Mar 27, 2013 at 8:19 AM, Alexandru C. [email protected]
wrote:

Hi Tom,

Thanks for the update. Is the fix for the failing ATSC build or the gcc 4.7?

Alex

Just the ATSC build. Not hugely important, but I thought we should get
it right.

The gcc 4.7 bug can’t be fixed on our side. It’s a known ICE problem,
and they need to patch it. I know they have a patch available, but I’m
not sure of the top of my head what version you need to get this. I
just know that the version installed in Ubuntu 12.10 still has this
bug.

Tom

On Wed, Mar 27, 2013 at 1:29 PM, Ralph A. Schmid, dk5ras
[email protected] wrote:

Well, it builds fine for me on Mint 13 64 bit, but note that we are
talking
about the “next” branch - the directory in your error message suggests
it’s
the master branch.

Aah, OK, missed this one; anyway, somehow master seems to make problems now.
I am not using next, as AFAIK the analog blocks still do not work as
expected. Or has this changed?

I don’t know about any issues with the analog blocks in gnuradio/next.
I only use the quadrature demodulator in c++ for FSK and that works
fine.

Alex

On Thu, Mar 28, 2013 at 12:30 AM, Tommy T. II [email protected]
wrote:

Ralph.

Ok, I recognize the problem, but I can’t replicate it on my Ubuntu
machines. It’s a SWIG issue where it looks like it thinks you’re
redefining typedef. It’s related to some fixes I made for the
processor affinity work and some typedefs that needed handling
differently.

I have a Mint 14 (64-bit) VM up and running and testing this there to
see if I can duplicate the problem.

Tom

On Thu, Mar 28, 2013 at 11:08 AM, Ralph A. Schmid, dk5ras
[email protected] wrote:

if I

can duplicate the problem.

If you need further information, just tell me what I should send, you in
case it may help. I have an image of the system at hand, backup/restore is a
matter of minutes (I love FLASH storage media!), so no risk to damage
anything :slight_smile: Just have in mind that I am not a Linux pro…

Tom

Ralph.

Well, my Mint 14 VM box finished up with no errors and all tests passed.

Can you just update your master branch to make sure it’s the absolute
latest and try again?

Tom

Can you just update your master branch to make sure it’s the absolute
latest
and try again?

I did this about two hours ago, with no success. Deleting the master
folder,
git clean -d -x -f, git pull, cd master, cmake …, make. Any changes
since
that? Then I will have another chance to test it again in a few hours.

Tom

Ralph.

On 28 Mar 2013 11:25, Ralph A. Schmid, dk5ras wrote:

Can you
just update your master branch to make sure it’s the absolute

latest

and try again?

I did this about two hours ago, with no
success. Deleting the master folder,
git clean -d -x -f, git pull, cd
master, cmake …, make. Any changes since
that? Then I will have
another chance to test it again in a few hours.

Different swig versions
on the two systems?

Different GCC versions?

Links:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs