Tried rebuilding qt-embedded statically using the arm linux compiler that
Bitbake uses for OE and am receiving the following error:
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.
On Fri, Feb 5, 2010 at 7:37 AM, <coderdrone@...> wrote:
> 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:
> -------From http://qt.nokia.com/doc/4.5/qt-performance.html
> 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
> 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 <dboddie@...:
>> coderdrone@... wrote:
>> >> 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.
>> Good luck! :-)
>> > 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
>> > would be easier on system resources on the gumstix if it was dynamic?
>> > not used to embedded development where resources are limited.
>> I think it's probably easier to put all the necessary libraries and
>> 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
>> 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
>> 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