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)
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?
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.
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.
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.
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.
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?
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?
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.
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?
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?
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.
The alternative is to copy these libraries in a separate
