Tried rebuilding qt-embedded statically using the arm linux compiler that Bitbake uses for OE and am receiving the following error:
overo-oe/tmp/cross/armv7a/bin/../libexec/gcc/arm-angstrom-linux-gnueabi/4.3.3/cc1plus: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory
Before rebuilding, I put the overo-oe/tmp/cross/arm7a/bin folder (with symlinks created) into my path. I didn't change any of the mkspecs, leaving the qws/linux-arm-g++ mkspec pointing to 'arm-linux-g++' compiler tools.
I read somewhere about staticly linking mpfr and some other tools for rebuilding GCC, but didn't even know GCC was being rebuilt, or how to go about this, or if this is what I even need.
It certainly wouldn't be difficult to copy the libraries and plugins to the SD card we'll be booting the board from, but it shouldn't be easier than copying a single executable. Also, the Performance Tuning page linked from the link you provided below seems to suggest static builds:
A lot of CPU and memory is used by the ELF (Executable and Linking Format)linking process. Significant savings can be achieved by using a static build of the application suite; rather than having a collection of executables which link dynamically to Qt's libraries, all the applications is built into into a single executable which is statically linked to Qt's libraries.
This improves the start-up time and reduces memory usage at the expense of flexibility (to add a new application, you must recompile the single executable) and robustness (if one application has a bug, it might harm other applications).-------
Our device will really only be running one application, so static shouldn't be a problem :)On Fri, Feb 5, 2010 at 6:47 AM, David Boddie <firstname.lastname@example.org> wrote:
email@example.com wrote:Good luck! :-)
>> Did you rebuild Qt with those compilers?
> oops... I've rebuilt Qt so many times with different configurations I
> forgot to do it with the right compiler. I'll try that in the morning
> when I get back to the office.
I think it's probably easier to put all the necessary libraries and plugins
> I was compiling our app statically to make it easier to deploy - 1
> executable instead of packaging with a bunch of libraries. I'm sure our
> actual software will be a bit bigger than the 14 megs though. Perhaps it
> would be easier on system resources on the gumstix if it was dynamic? I'm
> not used to embedded development where resources are limited.
on the device separately. You'll probably be copying the files directly to
the device (or onto a memory card), anyway, so it shouldn't be much more
Another thing you can do is to identify what features you will use and
exclude the ones you don't need from the Qt build. There's more information
about that here:
Note that you can use predefined library profiles, so you only have to
micromanage the feature set if you really want to.
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
gumstix-users mailing list