EmbDev.net

Forum: ARM programming with GCC/GNU tools missing libstdc++


von July J. (julyjim)


Attached files:

Rate this post
useful
not useful
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
von Rolf Magnus (Guest)


Rate this post
useful
not useful
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.

von pegel (Guest)


Rate this post
useful
not useful
Ist das nicht das 32 und 64 bit Problem?

von July J. (julyjim)


Rate this post
useful
not useful
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
von pegel (Guest)


Rate this post
useful
not useful

von July J. (julyjim)


Rate this post
useful
not useful
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:~ $

von pegel (Guest)


Rate this post
useful
not useful
May be the last 3 commands on the bottom on this page help:

https://wiki.debian.org/Multiarch/HOWTO

von July J. (julyjim)


Rate this post
useful
not useful
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:~ $

von Markus F. (mfro)


Rate this post
useful
not useful
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?

von pegel (Guest)


Rate this post
useful
not useful
Ich habe das so verstanden, dass der crosscompiler eine 32bit Version 
ist und die passende libstdc++ braucht. Meinst du nicht?

von July J. (julyjim)


Rate this post
useful
not useful
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?

von Markus F. (mfro)


Rate this post
useful
not useful
A complete mess.

If you want an answer in German language, why do you post on the English 
forum?

von July J. (julyjim)


Rate this post
useful
not useful
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
von July J. (julyjim)


Rate this post
useful
not useful
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.

von July J. (julyjim)


Rate this post
useful
not useful
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.

von pegel (Guest)


Rate this post
useful
not useful
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.

von Sheeva Plug (Guest)


Rate this post
useful
not useful
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.

von July J. (julyjim)


Rate this post
useful
not useful
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".

von July J. (julyjim)


Rate this post
useful
not useful
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.

von pegel (Guest)


Rate this post
useful
not useful
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?

von July J. (julyjim)


Rate this post
useful
not useful
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.

von Sheeva Plug (Guest)


Rate this post
useful
not useful
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.

von July J. (julyjim)


Rate this post
useful
not useful
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.

von July J. (julyjim)


Rate this post
useful
not useful
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
Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.