Problem with libstdc++

[Robert Kuhn]

Hello,
I do use angstrom, the 2.6.22-omap3-kernel and CodeSourcery from http://www.codesourcery.com/gnu_toolchains/arm/portal/release313

I do not have a problem compiling and running simple hello world-programs. But when I try to execute a bigger one I get this error:

./deviceinfo: /usr/lib/libstdc++.so.6: no version information available (required by ./deviceinfo)
./deviceinfo: /usr/lib/libstdc++.so.6: no version information available (required by ./deviceinfo)
./deviceinfo: /usr/lib/libstdc++.so.6: no version information available (required by ./deviceinfo)
./deviceinfo: /usr/lib/libstdc++.so.6: no version information available (required by /usr/local/lib/libxyz.so)

How can I solve this?

Robert

[Laurent Desnogues]

Just to make sure: did you copy the CodeSourcery libstdc++ into
your /usr/lib directory on the Beagle?

Laurent

[Koen Kooi]

On 9 okt, 15:19, "Laurent Desnogues" <laurent.desnog...@gmail.com>
wrote:

Eeks! Do you want to break all C++ apps on the device?

[Philip Balister]

Running apps built with one toolchain on a machine with a rootfs using
a different toolchain is a recipe for disaster. Well, at least some
painful debugging sessions.

Philip

>
> Robert
>
> >
>

[Laurent Desnogues]

On Thu, Oct 9, 2008 at 3:28 PM, Koen Kooi <koen...@gmail.com> wrote:
>
>> Just to make sure: did you copy the CodeSourcery libstdc++ into
>> your /usr/lib directory on the Beagle?
>
> Eeks! Do you want to break all C++ apps on the device?

Right :) The alternative is to copy these libraries in a separate
directory and play with LD_LIBRARY_PATH.

But Philip has the right solution: use the target libraries, not the
ones provided with CSL gcc.

Laurent

[Robert Kuhn]

Hello,

thank you for your answer. But what can I do? Recompile the whole Angstrom-Distribution? Use a different compiler?

Robert

2008/10/9 Philip Balister <philip....@gmail.com>

[John Beetem]

Robert,

Here's what I do to link BeagleBoard applications programs on my host
machine (PC running Windows 2000 and Cygwin). As suggested above, the
important thing is to make executables on your host machine that link
to the same Ångström libraries on BeagleBoard. What I did was to
untar the Ångström demo root file system on my PC, and then tell
CodeSourcery to link to the Ångström demo's libraries instead of the
defaults. All or most of these are dynamic shared libraries (.so).
Here are my gnu make commands:

# Set $(cc) to CodeSourcery GCC compiler and tell it to generate code
for armv7-a:
cc = arm-none-linux-gnueabi-gcc -O -Wunused -march=armv7-a

# Set $(RTdir) to PC directory containing Ångström demo run-time
libraries:
RTdir = /cygdrive/c/John/Beagle/AngstromDemo/usr/lib

# Set $(GXC_OBJS) to my list of object code files for my application:
GXC_OBJS = <list of object code files .o generated by $(cc)>

# Here is the GCC command to build my executable called "gboot".
# I need to specify RTdir both for -L and -rpath options.
gboot: $(GXC_OBJS)
$(cc) -o $@ $(GXC_OBJS) -L$(RTdir) \
-Xlinker -rpath -Xlinker $(RTdir) -lX11 -lm

The "-L" option tells the linker to look in $(RTdir) for .a files.
The "-rpath" linker option tells the linker to look in $(RTdir)
for .so files.
The "-Xlinker" option tells gcc to pass the next string to the
linker. You need an "-Xlinker" option for each string passed, so
"-Xlinker -rpath -Xlinker $(RTdir)" passes "-rpath $(RTdir)" to the
linker.

The linker generates a small executable that includes references to
the functions in the .so files, but does not include the bodies of
those functions. When you run that executable on Ångström, it finds
the .so files and dynamically links them in. If you linked your
program using these same .so files, the references will be correct and
Ångström will link them in correctly.

Hope this helps.

[Dirk Behme]

Sounds like this is worth adding to wiki/FAQ ;)

Dirk

[Robert Kuhn]

Hello John,

thank you, I will give it a try. I use OpenSUSE10.3 and will report any failure or sucess.

thanks again
Robert

2008/10/9 John Beetem <johnb...@yahoo.com>

[Philip Balister]

You can also try setting your path to
PATH=$(HOME)/oe/tmp/cross/armv7a/bin/ and using these tools. This has
worked for me in the past. This is the toolchain used by OE.

Philip

[Robert Kuhn]

Hello again :-)

2008/10/9 John Beetem <johnb...@yahoo.com>:

> Here's what I do to link BeagleBoard applications programs on my host

> machine...

I am still struggling with this problem.

I thought that when I am using Angstrom and CS2007q3 as compiler I do
not have this problem because Angstrom is build with CS2007q3 and so
when I use CS2007q3 too I link against the same libs?!?

Does Angstrom uses the CS2007q3 libs or does Angstrom compiles its own
libraries? How can I solve this when using linux? Is it the same like
on windows?

Thanks for any help or tips - Robert

[Robert Kuhn]

2008/10/9 Philip Balister <philip....@gmail.com>:

>
> You can also try setting your path to
> PATH=$(HOME)/oe/tmp/cross/armv7a/bin/ and using these tools. This has
> worked for me in the past. This is the toolchain used by OE.

I tried that without success. This is what I did:
* Install OE following the instructions from
http://elinux.org/BeagleBoardAndOpenEmbeddedGit
* changed PATH:
~/oe$ echo $PATH
/home/developer/oe/tmp/cross/armv7a/bin:/bin:/usr/bin
* Compiled qtopia for arm
* boot the beagle with the Angstrom-image
* try to execute a example program:
root@beagleboard:/usr/local/Trolltech/QtEmbedded-4.4.3-arm/examples/dialogs/findfiles#
./findfiles -qws
./findfiles: error while loading shared libraries: libstdc++.so.6:
cannot open shared object file: No such file or directory

My questions:

How can I solve this?

How can I build the Angstrom-X11-image?
Is there somewhere a description how to make a
cross-plattform-build-system for beginners like me?

Thankfull for any help - Robert

[Laurent Desnogues]

On Thu, Oct 23, 2008 at 12:26 PM, Robert Kuhn <rowk...@googlemail.com> wrote:
>
> 2008/10/9 Philip Balister <philip....@gmail.com>:
>>
>> You can also try setting your path to
>> PATH=$(HOME)/oe/tmp/cross/armv7a/bin/ and using these tools. This has
>> worked for me in the past. This is the toolchain used by OE.
>
> I tried that without success. This is what I did:
> * Install OE following the instructions from
> http://elinux.org/BeagleBoardAndOpenEmbeddedGit
> * changed PATH:
> ~/oe$ echo $PATH
> /home/developer/oe/tmp/cross/armv7a/bin:/bin:/usr/bin
> * Compiled qtopia for arm
> * boot the beagle with the Angstrom-image
> * try to execute a example program:
> root@beagleboard:/usr/local/Trolltech/QtEmbedded-4.4.3-arm/examples/dialogs/findfiles#
> ./findfiles -qws
> ./findfiles: error while loading shared libraries: libstdc++.so.6:
> cannot open shared object file: No such file or directory
>
>
> My questions:
> How can I solve this?

Try to add the directory containing the .so files to your LD_LIBRARY_PATH
environment variable on your Beagle.

Laurent

[Robert Kuhn]

>> root@beagleboard:/usr/local/Trolltech/QtEmbedded-4.4.3-arm/examples/dialogs/findfiles#
>> ./findfiles -qws
>> ./findfiles: error while loading shared libraries: libstdc++.so.6:
>> cannot open shared object file: No such file or directory
>>
>>
>> My questions:
>> How can I solve this?
>
> Try to add the directory containing the .so files to your LD_LIBRARY_PATH
> environment variable on your Beagle.

Sorry, forget to mention that:
root@beagleboard:/# find . -name libstdc,,*
root@beagleboard:/#

The Angstrom-consle-image does not contain this file (at least on my system).
Now I try to build a Angstrom-X11-Image. Is it correct that therefore
I have to change the line
DISTRO = "angstrom-2008.1"
in $OE_HOME/beagleboard/beagleboard/conf to something else?

Robert

[Koen Kooi]

On 23 okt, 12:26, "Robert Kuhn" <rowka...@googlemail.com> wrote:
> 2008/10/9 Philip Balister <philip.balis...@gmail.com>:

>
>
>
> > You can also try setting your path to
> > PATH=$(HOME)/oe/tmp/cross/armv7a/bin/ and using these tools. This has
> > worked for me in the past. This is the toolchain used by OE.
>
> I tried that without success. This is what I did:

> * Install OE following the instructions fromhttp://elinux.org/BeagleBoardAndOpenEmbeddedGit

> * changed PATH:
>  ~/oe$ echo $PATH
>  /home/developer/oe/tmp/cross/armv7a/bin:/bin:/usr/bin
> * Compiled qtopia for arm
> * boot the beagle with the Angstrom-image
> * try to execute a example program:
>  root@beagleboard:/usr/local/Trolltech/QtEmbedded-4.4.3-arm/examples/dialogs /findfiles#
> ./findfiles -qws
>  ./findfiles: error while loading shared libraries: libstdc++.so.6:
> cannot open shared object file: No such file or directory

Why aren't you using the qtembedded 4.4.3 from OE?

regards,

Koen

[Robert Kuhn]

2008/10/23 Koen Kooi <koen...@gmail.com>:

> Why aren't you using the qtembedded 4.4.3 from OE?

Cause I want to test if my cross plattform compile setup is correct
and working. qtopia was only an example.

Robert

[Robert Kuhn]

2008/10/23 Robert Kuhn <rowk...@googlemail.com>:

> Now I try to build a Angstrom-X11-Image. Is it correct that therefore
> I have to change the line
> DISTRO = "angstrom-2008.1"
> in $OE_HOME/beagleboard/beagleboard/conf to something else?

Okay, I found
bitbake x11-image
...

Robert

[Geof Cohler]

I agree that this is a general area of confusion. Once this
discussion settles in, I'll try to post to our wiki. But I have
questions about the gestalt. And these questions are because I'm
relatively new to the community approach.

The confusion arises from there being two (at least) different
environments being used on Beagle. There is the TI PSP Kernel
(2.6.22) that is in http://code.google.com/p/beagleboard/wiki/BeagleSourceCode
and elsewhere. And there is the Angstrom Kernel (2.6.26-27) that is
described in: http://code.google.com/p/beagleboard/wiki/HowToGetAngstromRunning.
Both use the same toolchain, but they have different libraries. So
applications need to be built twice -- once for TI Linux and once for
Angstrom Linux.

Over time, will this converge? Or over time, will people gravitate to
one platform so that developers don't have to build twice? Or will it
stay so that we essentially need to always build our own versions of
everything for our specific platforms? How does the community see
this playing out?

Thanks very much for your ideas here.

Best regards,
Geof


On Oct 23, 7:10 am, "Robert Kuhn" <rowka...@googlemail.com> wrote:
> 2008/10/23 Koen Kooi <koen.k...@gmail.com>:

[Robert Kuhn]

2008/10/23 Geof Cohler <g.co...@computer.org>:

>
> I agree that this is a general area of confusion. Once this
> discussion settles in, I'll try to post to our wiki. But I have
> questions about the gestalt. And these questions are because I'm
> relatively new to the community approach.
>
> The confusion arises from there being two (at least) different
> environments being used on Beagle. There is the TI PSP Kernel

I believe you should not mix the kernel on the one hand and the
Linux-images on the other side.

You can use TI's omap3-kernel or the git kernel with angstrom - as you
like it. (I think so, I used both without any problem).

The problem here is how to cross compile on a x86-linux-machine for
the beagleboard.

Robert

[Koen Kooi]

On 23 okt, 13:50, "Robert Kuhn" <rowka...@googlemail.com> wrote:
> The problem here is how to cross compile on a x86-linux-machine for
> the beagleboard.

And that's where you make a mistake. There's no such thing as "cross-
compiling for beagle". ARM has at least 10 different ABIs that can't
mixed (e.g. softfpa OABI, hardfpa OABI, EABI, etc). You need to
crosscompile things for the distribution you are running on a device,
not for the device itself.

regards,

Koen

[Robert Kuhn]

2008/10/9 Philip Balister <philip....@gmail.com>:

>
> You can also try setting your path to
> PATH=$(HOME)/oe/tmp/cross/armv7a/bin/ and using these tools. This has
> worked for me in the past. This is the toolchain used by OE.

Okay, now I was able to try that. I compiled qtopai this way. Then I
execute a sampel qt-application on Angstrom and I get:
root@beagleboard:/usr/local/Trolltech/QtEmbedded-4.4.3-arm/examples/dialogs/findfiles#
./findfiles -qws
./findfiles: /usr/lib/libstdc++.so.6: no version information available
(required by ./findfiles)
./findfiles: /usr/lib/libstdc++.so.6: no version information available
(required by ./findfiles)

I have no glue. Does this error message really indicates that I am
using different toolchains?
Robert

[Robert Kuhn]

2008/10/23 Koen Kooi <koen...@gmail.com>:

>> The problem here is how to cross compile on a x86-linux-machine for
>> the beagleboard.
>
> And that's where you make a mistake. There's no such thing as "cross-
> compiling for beagle". ARM has at least 10 different ABIs that can't
> mixed (e.g. softfpa OABI, hardfpa OABI, EABI, etc). You need to
> crosscompile things for the distribution you are running on a device,
> not for the device itself.

Hmm, okay, you're right. This is what I meant.

I installed OE on a Ubuntu machine as described on elinux.org. Then I
set the path to
PATH=$(HOME)/oe/tmp/cross/armv7a/bin/
Now when I compile I use the binaries in the path
(arm-angstrom-linux-gnueabi-*):
developer@ubuntu:~/oe/tmp/cross/armv7a/bin$ which
arm-angstrom-linux-gnueabi-gcc
/home/developer/oe/tmp/cross/armv7a/bin/arm-angstrom-linux-gnueabi-gcc

So I use Angstrom on the BB and I use the Angstrom toolchain. But I
get these error messages:

/usr/lib/libstdc++.so.6: no version information available

Robert

[Philip Balister]

Can you build a simple C++ program? I'm on the road atm and don't have
time to check.

Philip

[Robert Kuhn]

2008/10/23 Philip Balister <philip....@gmail.com>:

>
> Can you build a simple C++ program? I'm on the road atm and don't have
> time to check.

On my ubuntu x86-machine
developer@ubuntu:~$ echo $PATH
/home/developer/oe/tmp/cross/armv7a/bin:/bin:/usr/bin
developer@ubuntu:~$ echo $PATH
/home/developer/oe/tmp/cross/armv7a/bin:/bin:/usr/bin
developer@ubuntu:~$ cat main.c
#include <stdio.h>
int main(void)
{
printf("Hello, world!\n");
return 1;
}
developer@ubuntu:~$ arm-angstrom-linux-gnueabi-g++ main.c
developer@ubuntu:~$ file a.out
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for
GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped

on the BB:
root@beagleboard:/media/sda1# ./a.out
Hello, world!
root@beagleboard:/media/sda1#

Robert

[Robert Kuhn]

> developer@ubuntu:~$ file a.out
> a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for
> GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped

JFTR:
The qt-executable:
root@beagleboard:/usr/local/Trolltech/QtEmbedded-4.4.3-arm/examples/dialogs/findfiles#
file findfiles
findfiles: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for
GNU/Linux 2.6.14, dynamically linked (uses shared libs), stripped

Robert

[Philip Balister]

Try using iostream to get libstdc++ involved.

Philip

[Robert Kuhn]

>
> Try using iostream to get libstdc++ involved.

I used the Angstrom-X11-images (with libstdc++) and got the same warnings.

Robert

[Geof Cohler]

Hi,

Ok... I guess I should restate my question -- hopefully using the
correct terminology this time.

With several ARM ABI's, will the OMAP / Cortex products converge on a
single common ABI over time? Or do you expect that we always will
have the TI applications built to ABI #x and the Angstrom applications
built to ABI #y etc.?

It seems that if we (the community) were to settle in on one ABI, then
we could share binaries and eliminate the need to rebuild everything.

So I am just looking to understand why we are using different ABI's
other than early adopter miscoordination.

BTW, there is a very good tutorial on the gumstix website on the
basics of compiling hello world with Angstrom.

Thanks very much.

Best regards,
Geof

[Koen Kooi]

On 24 okt, 04:44, Geof Cohler <g.coh...@computer.org> wrote:
> Hi,
>
> Ok...  I guess I should restate my question -- hopefully using the
> correct terminology this time.
>
> With several ARM ABI's, will the OMAP / Cortex products converge on a
> single common ABI over time?  Or do you expect that we always will
> have the TI applications built to ABI #x and the Angstrom applications
> built to ABI #y etc.?

ABI is only one part of the story. Nowadays everyone should be using
EABI. But even if you use EABI you're going to have differences
between versions (e.g. glibc 2.4 vs 2.7, gcc 3.x vs 4.x) or C
libraries (e.g. glibc, uclibc, eglibc, newlib).
You just should *not* expect random binaries to work everywhere. And C+
+ has a tendency to break every other months with gcc, so if you want
to compile c++ apps, use the exact same toolchain and options that
your target was built with, it will save you a lot of trouble.
For opensource software the ABI story is a non-issue, you can rebuild
it easily and patch if needed (yes, mozilla, I'm looking at your
crappy hardcoded-fpa-abi js thing)

regards,

Koen

[Robert Kuhn]

2008/10/24 Koen Kooi <koen...@gmail.com>:

> + has a tendency to break every other months with gcc, so if you want
> to compile c++ apps, use the exact same toolchain and options that
> your target was built with,

JFTR: the exact same toolchain. The exact one.

I used the Angstrom image from your website together with a local
OE-toolchain. It seems that this was the problem.
Once I use the image from my local toolchain
(Angstrom-x11-image-glibc-ipk-2008.1-test-20081023-beagleboard.rootfs.tar)
my apps run without any warnings about "version information".

Robert

[Koen Kooi]

On 24 okt, 10:23, "Robert Kuhn" <rowka...@googlemail.com> wrote:
> 2008/10/24 Koen Kooi <koen.k...@gmail.com>:

That's probably because angstrom changed linker options (gnu hash to
get faster app startup). The packages all got a version bump, so
people keeping up to date with opkg should be ok[1].

regards,

Koen

[1] modulo a ppp-dialin postinst bug

[Geof Cohler]

Ah. This is very enlightening (to me at least).

So I can see two limits, and a middle ground in my view now (and of
course I will exaggerate to make the point)...

Case 1: Open Source
Things change with period approaching zero :-)
Implying you can't share binaries, and that you need to rebuild
everything -- because your toolchain may have changed.
So you have to strive for very accurate recipe dependencies in your
bitbake / make files -- to avoid having to rebuild every piece every
time.
And you can never use a binary as-is.

Case 2: The Bizarro Anti World -- Windows
Things change with a period approaching infinity :-)
Implying that you never have to rebuild anything.
And you can share binaries at will.
But you can never fix any bugs or change anything. You just need to
find workarounds and build them into your application.

Case 3: The Commercial Linux World
Things change with a moderate (every year or so) period.
Implying that you need to rebuild once a year or so to keep up.
And you can share binaries with other folks using the exact same
commercial release.
And that you may have to wait a year or so for a bug fix. And will
need a workaround until then.

So this all shows that the price of Case 1 (aka freedom) is eternal
vigilance. It shows why some people form authoritarian governments
(Case 2). And it shows why societies can form where people agree to
accept some restrictions in exchange for peace (Case 3).

Thanks very much to all for this discussion. It shed great light for
me.

Best regards,
Geof

[quang....@gmail.com]

I just found out that you need to install libstdc++6 package in Angstrom with opkg.
Try this command in your debug terminal.
opkg install libstdc++6

Thanks
Quang Do