Re: [Libjpeg-turbo-devel] libjpeg-turbo 1.2 release schedule?

[DRC <dco...@us...>]

On 10/19/11 2:38 AM, Martin Aumüller wrote:
>> (1) Building dynamic libs works fine for me.  Why did you specify static
>> above?
> 
> Apple does not allow dynamic linking against non-system libraries: apps doing that are simply killed while starting up, before main() is even reached.

OK, BUILDING.txt has been modified accordingly.


>> (2) Shouldn't -O3 be included in CFLAGS?  Otherwise, this will build
>> without optimization.
> 
> Probably yes: it was just silly of me to assume that autotools would handle that while I was overriding CFLAGS.

It wasn't silly of you.  It's silly of autotools not to handle it
automatically.  :)  That's one advantage of CMake.


>> (3) Since I generate Mac packages as part of the LJT distribution, it
>> would be straightforward to include ARM variants into those same
>> universal binaries.  Does that make sense at all?  Would it be generic
>> enough to be beneficial to iOS developers, or is there too much that
>> depends on the SDK version?
> 
> I think it would be useful for iOS developers to have a universal static library containing the two ARM variants and i686 (for the simulator) precompiled.

Ideally, what I'd really like is to be able to include the iOS and x86
versions in one package, but that's not straightforward, since the
packaging system currently assumes only two architectures and also
assumes the presence of dynamic libs.  I don't really have time to mess
with overhauling it.  Also, releasing a second package just for iOS
creates potential directory conflicts with the x86 package, and I don't
want to add to our already-growing list of packages unless there is a
large demand.  Thus, for now, I think it's probably best to just
maintain the build instructions and not put out an iOS binary package.

Perhaps Apple will consider integrating libjpeg-turbo into their O/S's,
now that it is released under a commercially-friendly license.