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.
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.
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 to std::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 to std::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 to std::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 to std::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 to std::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 to std::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 to std::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 to std::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
alc@vega ~/sdr/gnuradio/v3.6.4.1-946-g7f0d3777-next/build $
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 to std::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
alc@vega ~/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?
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.
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?
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
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.
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.
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.
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 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?
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.
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.
Just have in mind that I am not a Linux pro…