On WWDC 2010 we noticed some changes to Section 3.3.2 of Apple’s licensing agreement — specifically the part that deals deals with the use of cross-compilers. The changes this time around may not make things all better, but it could make things slightly better for some developers. Matt Drance had this to say about the change to Section 3.2.2:

“While explicit approval from Apple is still required, these new terms seem to acknowledge that there’s a difference between an app that happens to have non-compiled code, and a meta-platform. It’s a step that should allow for many new possibilities.”

And because of the features of Lua,

Lua is a powerful, fast, lightweight, embeddable scripting language.
Lua combines simple procedural syntax with powerful data description constructs based on associative arrays and extensible semantics. Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection, making it ideal for configuration, scripting, and rapid prototyping.

,
then one guy wrote two tutorials, Integrating Lua into an iPhone App and Remote Debugging for Lua on the iPhone.
If you are not familiar with Xcode but familiar with Lua, maybe you can try iLuaBox.

P.S.

iLuaBox is an iOS application that hosts the Lua scripting environment. iLuaBox provides an intuitive environment to learn, write, and test scripts written in the Lua Programming Language. This is not a stripped down version of Lua, but rather a full-featured implementation that is optimized for iOS and the iPad hardware platform.

libjpeg is a library written entirely in C which contains a widely-used implementation of a JPEG decoder, JPEG encoder and other JPEG utilities. This library is maintained by the Independent JPEG Group.

libjpeg-turbo is a high-speed version of libjpeg for x86 and x86-64 processors which uses SIMD instructions (MMX, SSE2, etc.) to accelerate baseline JPEG compression and decompression. libjpeg-turbo is generally 2-4x as fast as the unmodified version of libjpeg, all else being equal(for non-grayscale JPEG compression and decompression, libjpeg-turbo is between 1.8x and 4.5x as fast as libjpeg v6b).

libjpeg-turbo was originally based on libjpeg/SIMD by Miyasaka Masaru, but the TigerVNC and VirtualGL projects made numerous enhancements to the codec, including improved support for Mac OS X, 64-bit support, support for 32-bit and big endian pixel formats (RGBA, ABGR, etc.), accelerated Huffman encoding/decoding, and various bug fixes. The goal was to produce a fully open source codec that could replace the partially closed source TurboJPEG/IPP codec used by VirtualGL and TurboVNC. libjpeg-turbo generally achieves 80-120% of the performance of TurboJPEG/IPP. It is faster in some areas but slower in others(for non-grayscale JPEG compression and decompression, libjpeg-turbo 64-bit is between 80% and 118% as fast as TurboJPEG/IPP. libjpeg-turbo 32-bit is between 60% and 93% as fast as TurboJPEG/IPP. libjpeg-turbo’s primary weakness relative to TurboJPEG/IPP is 32-bit performance, particularly on Intel processors and even more particularly on legacy Intel processors. This is largely due to the Huffman encoder/decoder running out of registers and having to swap some inner loop variables back and forth from memory).

In one word, libjpeg-turbo is a fork of libjpeg that uses SIMD instructions to accelerate JPEG encoding and decoding.

btw, projects such as Mozilla and fedora switched to libjpeg-turbo in 2010.

References,
libjpeg-turbo HomePage
Independent JPEG Group’s JPEG software release 6b
with x86 SIMD extension for IJG JPEG library version 1.02
Independent JPEG Group(IJG)

After successfully statically compile Qt 4.6.3 under Unbuntu 10.04 Server, I tried to build static version fancybrowser, after some study, I got a static execute, but when ran it, it suspended before load url, I do not know why, after some search I got the following answer,

> Is it possible to build a completely static app using Qt 4 on Linux?

Completely static? No.

Almost completely static? Yes. The GNU Libc library’s NSS subsystem still
requires dynamic loading of some modules in order to fullfil your requests,
especially when it comes to DNS resolution. If you don’t use QTcpSocket or
QHostInfo, you probably will get a fully static binary though.

Make sure you have static libs for all Qt dependencies. They will be linked
into your executable, which will be several megabytes in size.

Better than that is to have Qt as a static library, but nothing else. That
will link Qt into your program, but will dynamically load the libraries it
needs from the system.

I believe that’s the approach that Skype uses on their static binaries.

> My problem is I’m trying to build an application that will run on a
> variety of recent (2.6.x kernel) distros. My first attempt (using shared
> libraries) results in “Floating point exceptions” when run on Debian. So
> now I’m looking at building statically.

My suggestion is to try the linux-lsb-g++ mkspec if you intend to deploy a Qt
application in several different Linux systems.

But I don’t see how floating point exceptions can have anything to do with the
Qt build. Maybe if you post a code sample and/or a backtrace of the crash, we
can help with that instead.

Be sure that you build your application on the “lowest common denominator”
platform of yours, since libc and libstdc++ are not forwards compatible
(i.e., you have to link to the lowest version you intend to deploy on).

This applies even if you replace the headers of those libraries with older
headers. (There’s a link-time dependency, whereas Qt is only compile-time)

> I was able to add a -static flag to my link flags in my .pro file, and
> I’m linking against static Qt libs, but when it gets to linking in
> libSM, it only finds the dynamic version and stops. I’m sure this is
> also the case for most of the X11 libraries.

Like I said above, you need to have the static library for all dependencies if
you want to have a fully static build.

> Can this be made to work? Or am I stuck building dynamically on a
> multitude of distros?

There’s always LSB.

The recently-announced LSB 3.2 contains Qt 4.2 as part of the required
standard. Any Linux distribution conforming to LSB 3.2 will have that. Most
recent Linux distributions already ship Qt 4.2 or even 4.3 (thanks to the KDE
4 release).

The previous LSB 3.1 standard contained Qt 4.1 but only as an optional module.
It has been out for close to 2 years now, though, so you may have a wider
variety of distribution targets.