I'll apology up front so do not flame me. I am really not getting any help from Eclipse - TCF so that is why I am asking here. Yes, I did google for answer but was not successful. My application is simple C++ using crosscompiler - my =host is x86 running Ubuntu and target is in Raspberry Pi ARM. I am using TCF to communicate with Agent on RPi. It works, until I try to add a class to output to the RPi pins. Than I get this error about missing libstdc++ on the target system. The problem is I did check the RPi and it does have the latest libstdc++ installed. The other problem - no matter what I do I cannot get rid of the error - until I reinstalled Eclipse (Oxygen) and imported my original code WITHOUT the new class. In short - the error gets stuck in TCF. Removing the class include does not help. BYpassing the class source code does not help either. I know this sounds complicated - but I have no idea how to troubleshoot the issue. I am NOT expecting / asking for a solution , just some advise how to find out why TCF is complaining about missing library. Apparently the new class I have build - not my code - is causing the issue. I can add default C++ class without any problems. Thanks for any advise. Cheers SOrry, I do not have acces to jpg file. Addendum If I bypass both header and source file and remove the #include I get rid of the "missing library error. If I bypass all function in the class leaving only my test function ( print) function I still get the missing library error. Possibly some of the includes used by the class is causing the error? .
: Edited by User
July J. wrote: > Than I get this error about missing libstdc++ on the target system. The message in your screenshot doesn't say that libstdc++ is missing. It says that the glibc is the wrong version and doesn't match the version libstdc++ is expecting.
Ist das nicht das 32 und 64 bit Problem?
Thanks, I have narrowed it down to usage of "string". I do not have to use "string" if that is a big issue. But the obvious question is - how do I install this "so.6" and its proper version? I'll try to figure that myself. One more question - what does "so" stands for? Thanks. Vielen Dank Vielleicht ist es , der Host (x86) ist 64 Bit Ubuntu OS und Ziel läuft auf 32 Bit Raspbian (ARM), eine Art Betriebssystem. Es ist der ARM, der sich beschwert.
: Edited by User
https://embdev.net/topic/440479#postform Suggestion worked only partially Perhaps this last command is incomplete ? pi@pi:~ $ sudo tzdata libdb1-compat libc-bin initscripts pi@pi:~ $ sudo apt-get install libc6:i386 libstdc++6:i386 Reading package lists... Done Building dependency tree Reading state information... Done Package libc6:i386 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: tzdata libdb1-compat libc-bin initscripts Package libstdc++6:i386 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'libc6:i386' has no installation candidate E: Package 'libstdc++6:i386' has no installation candidate pi@pi:~ $ tzdata libdb1-compat libc-bin initscripts -bash: tzdata: command not found pi@pi:~ $ sudo tzdata libdb1-compat libc-bin initscripts sudo: tzdata: command not found pi@pi:~ $
May be the last 3 commands on the bottom on this page help: https://wiki.debian.org/Multiarch/HOWTO
Still no go I need to read the entire link Package libstdc++6:i386 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source Package zlib1g:i386 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'libstdc++6:i386' has no installation candidate E: Package 'libgcc1:i386' has no installation candidate E: Package 'zlib1g:i386' has no installation candidate E: Package 'libncurses5:i386' has no installation candidate pi@pi:~ $
July J. wrote: > E: Package 'libstdc++6:i386' has no installation candidate > E: Package 'libgcc1:i386' has no installation candidate > E: Package 'zlib1g:i386' has no installation candidate > E: Package 'libncurses5:i386' has no installation candidate > pi@pi:~ $ it probably doesn't make much sense to try and install i368 arch packages on a pi?
Ich habe das so verstanden, dass der crosscompiler eine 32bit Version ist und die passende libstdc++ braucht. Meinst du nicht?
Das ist eine Frage, die ich mir nicht angeschaut habe, die ich nicht beantworten konnte. Ich kann eine ausführliche Ausgabe veröffentlichen, wenn es interessiert ist, es kann Three sein, aber ich habe keinen Grund, das zu überprüfen. Ich habe das so geändert, dass der Crosscompiler eine 32bit Version ist ist und die passende libstdc ++ braucht. Meinst du nicht?
A complete mess. If you want an answer in German language, why do you post on the English forum?
Yes, if i386 is a hardware "architecture" and this is what Raspberry Pi architecture is pi@pi:~ $ dpkg --print-architecture armhf pi@pi:~ $ I wonder how "string" reacts when compiled directly (gcc c++) on RPi. Maybe this is actually TCF communication problem. PS I need to take a break, I'll be back in few days. Thanks
: Edited by User
Because some participant posted in German. If that is a problem for you you have an option NOT to participate instead of making such remarks which does not contribute one iota to the discussion.
This issue has been brought up before elsewhere. The key is - the MISSING version GLIBCXX_3.4.21. It is unclear HOW and WHAT application is using this apparently rogue version - not part of current Raspian OS. It could be gcc or TCF. Really does not matter which one, BTW the latest libstdc++ is version 7, but that does not help. Here is what is in my current RPi under libstdc++ 6 pi@pi:/usr/lib/arm-linux-gnueabihf $ strings /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | grep GLIBCXX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 GLIBCXX_3.4.18 GLIBCXX_3.4.19 GLIBCXX_3.4.20 GLIBCXX_DEBUG_MESSAGE_LENGTH To resolve the problem I need a SIMPLE way to FIND this 3.4.21 and install it on armhf architecture. I find it odd that anybody would mess with "standard c++" library to make it incompatible with newest release.
https://community.emlid.com/t/problems-with-libstdc-glibcxx-3-4-21-not-found/6369/5 http://www.hertaville.com/development-environment-raspberry-pi-cross-compiler.html "The binaries execute perfect on the older image, but on the new one this specific software complains about GLIBCXX_3.4.21 ." Please read the answer from Christopher Chavez. This could be the solution.
July J. wrote: > The key is - the MISSING version GLIBCXX_3.4.21. > [...] > To resolve the problem I need a SIMPLE way to FIND this 3.4.21 and > install it on armhf architecture. I suspect it'd be better to install a compatible GLIBC version into your cross compiler toolchain and link against that -- or rather to compile and link your programm on the target.
The above links are indeed helpful to define and describe how crosscompliling works. It does not quite fit into my case where TCF does the communication between host and target. I'll admit that I do not fully understand the details of TCF Agent, but I believe it takes care of having proper packages setup in host . The link "tutorial" builds such packages ( in host ) manually. Maybe it should be also noted that these were written in 2014. The tutorial also DOES NOT use "string" - a variable which needs the "missing " libstdc++ version. To reiterate - I have no issues doing std:cout << , but when I add "string TestString"; I get the missing file version error - from target - RPi, The only (real ) solution I see so far is to get a Rasbpian copy of GLIBCXX_3.4.21. Or hack solution in not using "string".
AS I said - this is my first crosscomplie application and I am really not sure how gcc and TCF works together. The error comes from target and the host is where the app is successfully complied and via TCF "transferred" to the target. The whole idea of crosscompiling is to compile on host because the target has limited resources , and its OS is not suitable for C++ development. Crosscompiling works - it is the "missing " version of GLIBCXX which is not present on target. The question is - how to JUST add the missing version to the target OS. Maybe Rasbpian forum is my next option to check.
Christopher Chavez wrote: "I believe I have identified the cause of this issue or at least was able to resolve it." "After removing the toolchain installed by the package manager, we refreshed our project files to point to the libraries in the toolchain the tutorial was recommending, and were able to run" Dosen't that work for you?
pegel wrote: > Christopher Chavez wrote: > > "I believe I have identified the cause of this issue or at least was > able to resolve it." > > "After removing the toolchain installed by the package manager, we > refreshed our project files to point to the libraries in the toolchain > the tutorial was recommending, and were able to run" > > Dosen't that work for you? I do appreciate your support, however, the link you are referring to did not prove that it works when "string" class is used. They do use std::cout and that works in my app. I really need to figure out how to let the target to use correct version of the GLIBCXX Somewhere in cross gcc must be an option to copy correct GLBCXX to the target. And yes , I have no issue using "string" on host itself. It is just the target does not get the required version of the GLINCXX.
July J. wrote: > Crosscompiling works - it is the "missing " version of GLIBCXX which is > not present on target. And this only happens because you use a newer glibc in your cross-compiler environment, so your cross-compiler is not set up correctly even though it seems to work. So, just downgrade the version you link with to the version that is installed on your RPi. Yes, it's simple as that. Another solution might be to statically link your program.
Addendum I got upset and did the following Removed current Eclipse 3.8 from the Raspberry Pi. Downloaded current version of Rasbpian Eclipse 3.8.2 Reinstalled CDT and wrote test program using #include <string> and it compiled and run with verson gcc x - I have a copy of verbose compilation if details would be helpful for discussion. Installed Eclipse 3.8 version from Eclipse source. Hand a heck of a time "installing CDT and CROSS_GCC. Wrote simple TEST_LINUX to run as "local application" no problem Wrote simple TEST_GROSS to run on the host - no problem. Added #include <string> - no problem. Added instance of string class - BACK TO SAME ISSUE - MISSING libstdc+ GLIBCXX version. So both versions of Eclipse 3.8.2 and SAME version if Cross GCC produce same problem - the libstdc++ do not match, as far as I can tell OR I have no idea how to instruct the target to use HIGHER version of libstdc++. PS Early in my project development I decided to use gross-compiling because Raspberry Pi RASPBIAN OS is a slow dog as far as developing C++ and or run few apps on desktop. Not a viable option, has nothing to do with hardware - it is the OS which stinks.
I am sure I found the "problem". On x86 the Eclipse IDE uses libstdc++-v3 library and has no issue with class string. There is no libstdc++ GLIBCXX on the system - Ubuntu. On ARM the "system AKA Raspbian" wants to link to libstdc++ GLIBCXX version with last number 21 - but has LAST version as 20. Apparently the libstdc++ versioning designation has changed - I do not have the link to such note, but I have red it somewhere. No, I do not wnat to develop on Raspberry and I hope someone have a idea how to crosscompile and have access to string class. In the meantime I am ditching using string class. Cheers
: Edited by User