Error when attempting to remote debug a Beaglebone
I'm trying to put together a Qt Creator environment so I can remotely debug a Beaglebone Black. With help, I've successfully built Qt, so I now have a qmake that I can use. I can build without incident. When I start the debugger, though, I get this result:
Debugging starts Listening on port 10000 Remote debugging from host 192.168.0.3 Process /home/mzimmers/Qt/makeLEDOOP_Qt created; pid = 2525 /home/mzimmers/Qt/makeLEDOOP_Qt: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/mzimmers/Qt/makeLEDOOP_Qt) Child exited with status 1 Debugging has finished
My (beginner's) interpretation is that I have an out-of-date library file. Does this seem like the right interpretation? And, is it referring to the file on my desktop (not the BBB)?
On both systems, libstdc++.so.6 is a link to libstdc++.so.6.0.20, which exists in the same directory. So, I'm not sure what's going on.
Any ideas would be much appreciated. Thanks...
EDIT: some additional information...
mzimmers@debian:/usr/lib/arm-linux-gnueabihf$ nm -D libstdc++.so.6.0.20 | grep GLIBC 00000000 A GLIBCXX_3.4 00000000 A GLIBCXX_3.4.1 00000000 A GLIBCXX_3.4.10 00000000 A GLIBCXX_3.4.11 00000000 A GLIBCXX_3.4.12 00000000 A GLIBCXX_3.4.13 00000000 A GLIBCXX_3.4.14 00000000 A GLIBCXX_3.4.15 00000000 A GLIBCXX_3.4.16 00000000 A GLIBCXX_3.4.17 00000000 A GLIBCXX_3.4.18 00000000 A GLIBCXX_3.4.19 00000000 A GLIBCXX_3.4.2 00000000 A GLIBCXX_3.4.20 00000000 A GLIBCXX_3.4.3 00000000 A GLIBCXX_3.4.4 00000000 A GLIBCXX_3.4.5 00000000 A GLIBCXX_3.4.6 00000000 A GLIBCXX_3.4.7 00000000 A GLIBCXX_3.4.8 00000000 A GLIBCXX_3.4.9 mzimmers@debian:/usr/lib/arm-linux-gnueabihf$
Same result on the BBB.
So, how is it that my project seems to be requesting a version of a library element that I don't have?
Can you check which version of gcc you would get on your BBB ?
Hi SGaist -
In /usr/bin it looks like 4.9.
The cross-compiler you used is at 6.2.1, that might be the issue here.
I guess I don't really understand what the problem is. The libraries on the host an d the BBB are identical (at least from the standpoint of which versions they contain). Where is the request for this missing version 3.4.21 coming from?
I will look for a newer version of the toolchain for the BBB on linaro.
So I attempted to retrieve the latest version of the GNU ARM toolchain using this command:
sudo apt-get install build-essential
But it said I already have the latest version of build-essential.
Where else can I get this package? Or do I need to just download onto my desktop and use ftp or something to transfer the files to the BBB?
Just to be on the safe side, I'd recommend rebuilding Qt with the Linaro 4.9 cross-compiler. You can find it here along with the matching sysroot.
That way you should be using the same set of libraries. Furthermore, rather than use the Linaro sysroot, you could use your BBB root filesystem as sysroot, so you'd ensure that you'll be linking with the same libraries your application should run with.
Thanks, Mr. Gaist. Am I correct in assuming the file I want is:
And, regarding using the BBB file system as sysroot, this would mean I'd need a copy of that filesystem on my desktop (where I'm building Qt), right?
Looks good yes.
As for the sysroot, you can either copy it or you could also mount it using e.g. sshfs.
That means having your BBB powered up and running a ssh server which is likely already the case. The pros is that if you are missing a dev package you can just log into your BBB, add it and it will be directly available for cross-compilation. The cons is that you need to have your device powered up and running but all in all it will likely be the case anyway so it's up to you.
Thanks...I'm running make right now. It will be interesting to see whether I have to run make install this time, as I did last time despite the instructions saying I didn't have to.
So, if I simply make a copy of the / directory on the BBB, and put it somewhere on my desktop system, I could use that as my sysroot for the build (asking for future reference)?
Hi, SGaist -
I was wondering whether I'd ever see the day when we got there, but...we got there. I just successfully launched the debugger and ran an example from Molloy's chapter 5 (manipulating the on-board LEDs).
I'd like to thank you profusely for your help in getting this done. Come to the states sometime, and I'll buy you a beer or three...
Happy hacking then :)
Don't forget to mark the thread as solved using the "Topic Tools" button ;)