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
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
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.
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)
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".
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].
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.
