libjpeg-turbo-users

[Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[Pol-Online <in...@po...>]

Hi,  

I’ve been trying to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7 for some time but without success as it fails on the NEON instructions. I used to do it without problem with Xcode 4.x / iOS 6. I’m compiling the library on a completely stock OS X with just Xcode and developer command line tools installed on top of it.

I found this old thread http://sourceforge.net/mailarchive/message.php?msg_id=30462917 and tried the autoreconf tip, but it doesn’t fix the issue.

Here’s the build script I use:
https://gist.github.com/swisspol/8498104

And here’s the full output:
https://gist.github.com/swisspol/8498120

With the failure part here:

/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in java
echo timestamp > classnoinst.stamp
Making all in simd
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc -E -I.. -I../simd ./jsimdcfg.inc.h | /usr/bin/grep -E "^[\;%]|^\ %" | sed 's%_cpp_protection_%%' | sed 's@% define@%define@g' > jsimdcfg.inc
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
/bin/sh ../libtool  --tag=CC   --mode=compile /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H -I. -I..  -I..  -O3 -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk  -O3 -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -miphoneos-version-min=5.0 -MT jsimd_arm.lo -MD -MP -MF .deps/jsimd_arm.Tpo -c -o jsimd_arm.lo jsimd_arm.c
/bin/sh ../libtool    --mode=compile gas-preprocessor.pl /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H -I. -I..  -I..  -O3 -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk  -O3 -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -miphoneos-version-min=5.0 -MT jsimd_arm_neon.lo -MD -MP -MF .deps/jsimd_arm_neon.Tpo -c -o jsimd_arm_neon.lo jsimd_arm_neon.S
libtool: compile:  /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H -I. -I.. -I.. -O3 -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -O3 -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -miphoneos-version-min=5.0 -MT jsimd_arm.lo -MD -MP -MF .deps/jsimd_arm.Tpo -c jsimd_arm.c -o jsimd_arm.o
libtool: compile:  gas-preprocessor.pl /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H -I. -I.. -I.. -O3 -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -O3 -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -miphoneos-version-min=5.0 -MT jsimd_arm_neon.lo -MD -MP -MF .deps/jsimd_arm_neon.Tpo -c jsimd_arm_neon.S -o jsimd_arm_neon.o
mv -f .deps/jsimd_arm.Tpo .deps/jsimd_arm.Plo
clang: warning: argument unused during compilation: '-D HAVE_CONFIG_H'
clang: warning: argument unused during compilation: '-I .'
clang: warning: argument unused during compilation: '-I ..'
clang: warning: argument unused during compilation: '-I ..'
clang: warning: argument unused during compilation: '-MT jsimd_arm_neon.lo'
clang: warning: argument unused during compilation: '-MD'
clang: warning: argument unused during compilation: '-MP'
clang: warning: argument unused during compilation: '-MF .deps/jsimd_arm_neon.Tpo'
jsimd_arm_neon.S:270:16: error: invalid operand for instruction
      ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 1 * 8))]
               ^
jsimd_arm_neon.S:276:16: error: invalid operand for instruction
      ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 2 * 8))]
               ^
jsimd_arm_neon.S:283:16: error: invalid operand for instruction
      ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 3 * 8))]
               ^
jsimd_arm_neon.S:291:16: error: invalid operand for instruction
      ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 4 * 8))]
               ^
jsimd_arm_neon.S:299:16: error: invalid operand for instruction
      ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 5 * 8))]
               ^
jsimd_arm_neon.S:306:16: error: invalid operand for instruction
      ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 6 * 8))]
               ^
jsimd_arm_neon.S:313:16: error: invalid operand for instruction
      ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 7 * 8))]
               ^
jsimd_arm_neon.S:321:16: error: invalid operand for instruction
      ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 0 * 8))]
               ^
make[3]: *** [jsimd_arm_neon.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


Any help appreciated!

PS: I understand one can grab the precompiled binaries from sourceforge, but I like to compile it myself and slightly customize it.

PS 2: I also maintain a project on GitHub with ready-to-use build script for various popular open-source libraries on OS X / iOS: https://github.com/swisspol/Libraries. I’ll update the libjpeg-turbo one as soon as I can make it work again.

-Pol

________________________________
Pol-Online
in...@po... (mailto:in...@po...)

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[Siarhei S. <sia...@gm...>]

On Sat, 18 Jan 2014 15:15:39 -0800
Pol-Online <in...@po...> wrote:

> Hi,  
> 
> I’ve been trying to compile libturbo-jpeg for iOS devices with Xcode 5 /
> iOS 7 for some time but without success as it fails on the NEON
> instructions. I used to do it without problem with Xcode 4.x / iOS 6.
> I’m compiling the library on a completely stock OS X with just Xcode
> and developer command line tools installed on top of it.
> 
> I found this old thread http://sourceforge.net/mailarchive/message.php?msg_id=30462917
> and tried the autoreconf tip, but it doesn’t fix the issue.
> 
> Here’s the build script I use:
> https://gist.github.com/swisspol/8498104
> 
> And here’s the full output:
> https://gist.github.com/swisspol/8498120
> 
> With the failure part here:

[...]

> mv -f .deps/jsimd_arm.Tpo .deps/jsimd_arm.Plo
> clang: warning: argument unused during compilation: '-D HAVE_CONFIG_H'
> clang: warning: argument unused during compilation: '-I .'
> clang: warning: argument unused during compilation: '-I ..'
> clang: warning: argument unused during compilation: '-I ..'
> clang: warning: argument unused during compilation: '-MT jsimd_arm_neon.lo'
> clang: warning: argument unused during compilation: '-MD'
> clang: warning: argument unused during compilation: '-MP'
> clang: warning: argument unused during compilation: '-MF .deps/jsimd_arm_neon.Tpo'
> jsimd_arm_neon.S:270:16: error: invalid operand for instruction
>       ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 1 * 8))]
>                ^
> jsimd_arm_neon.S:276:16: error: invalid operand for instruction
>       ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 2 * 8))]
>                ^
> jsimd_arm_neon.S:283:16: error: invalid operand for instruction
>       ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 3 * 8))]
>                ^
> jsimd_arm_neon.S:291:16: error: invalid operand for instruction
>       ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 4 * 8))]
>                ^
> jsimd_arm_neon.S:299:16: error: invalid operand for instruction
>       ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 5 * 8))]
>                ^
> jsimd_arm_neon.S:306:16: error: invalid operand for instruction
>       ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 6 * 8))]
>                ^
> jsimd_arm_neon.S:313:16: error: invalid operand for instruction
>       ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 7 * 8))]
>                ^
> jsimd_arm_neon.S:321:16: error: invalid operand for instruction
>       ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 0 * 8))]
>                ^
> make[3]: *** [jsimd_arm_neon.lo] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> 
> Any help appreciated!

It looks like the iOS assembler got some upgrade (as part of
the migration to clang?). Currently libjpeg-turbo relies on
https://github.com/yuvi/gas-preprocessor to provide something
that can be digested by the iOS ARM assembler. It may be a good
idea to report this issue to the developers of gas-preprocessor
and ask for a piece of advice.

-- 
Best regards,
Siarhei Siamashka

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[Pol-Online <in...@po...>]

OK, I created a GitHub issue here:  
https://github.com/yuvi/gas-preprocessor/issues/26

Independently of that, can anyone successfully compile libjpeg-turbo w/ Neon support with Xcode 5? Maybe the issue is in my build script.  


-Pol

________________________________
Pol-Online
in...@po... (mailto:in...@po...)


On Tuesday, January 21, 2014 at 11:11 AM, Siarhei Siamashka wrote:

> On Sat, 18 Jan 2014 15:15:39 -0800
> Pol-Online <in...@po... (mailto:in...@po...)> wrote:
>  
> > Hi,  
> >  
> > I’ve been trying to compile libturbo-jpeg for iOS devices with Xcode 5 /
> > iOS 7 for some time but without success as it fails on the NEON
> > instructions. I used to do it without problem with Xcode 4.x / iOS 6.
> > I’m compiling the library on a completely stock OS X with just Xcode
> > and developer command line tools installed on top of it.
> >  
> > I found this old thread http://sourceforge.net/mailarchive/message.php?msg_id=30462917
> > and tried the autoreconf tip, but it doesn’t fix the issue.
> >  
> > Here’s the build script I use:
> > https://gist.github.com/swisspol/8498104
> >  
> > And here’s the full output:
> > https://gist.github.com/swisspol/8498120
> >  
> > With the failure part here:
>  
> [...]
>  
> > mv -f .deps/jsimd_arm.Tpo .deps/jsimd_arm.Plo
> > clang: warning: argument unused during compilation: '-D HAVE_CONFIG_H'
> > clang: warning: argument unused during compilation: '-I .'
> > clang: warning: argument unused during compilation: '-I ..'
> > clang: warning: argument unused during compilation: '-I ..'
> > clang: warning: argument unused during compilation: '-MT jsimd_arm_neon.lo'
> > clang: warning: argument unused during compilation: '-MD'
> > clang: warning: argument unused during compilation: '-MP'
> > clang: warning: argument unused during compilation: '-MF .deps/jsimd_arm_neon.Tpo'
> > jsimd_arm_neon.S:270:16: error: invalid operand for instruction
> > ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 1 * 8))]
> > ^
> > jsimd_arm_neon.S:276:16: error: invalid operand for instruction
> > ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 2 * 8))]
> > ^
> > jsimd_arm_neon.S:283:16: error: invalid operand for instruction
> > ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 3 * 8))]
> > ^
> > jsimd_arm_neon.S:291:16: error: invalid operand for instruction
> > ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 4 * 8))]
> > ^
> > jsimd_arm_neon.S:299:16: error: invalid operand for instruction
> > ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 5 * 8))]
> > ^
> > jsimd_arm_neon.S:306:16: error: invalid operand for instruction
> > ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 6 * 8))]
> > ^
> > jsimd_arm_neon.S:313:16: error: invalid operand for instruction
> > ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 7 * 8))]
> > ^
> > jsimd_arm_neon.S:321:16: error: invalid operand for instruction
> > ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 0 * 8))]
> > ^
> > make[3]: *** [jsimd_arm_neon.lo] Error 1
> > make[2]: *** [all] Error 2
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2
> >  
> >  
> > Any help appreciated!
>  
> It looks like the iOS assembler got some upgrade (as part of
> the migration to clang?). Currently libjpeg-turbo relies on
> https://github.com/yuvi/gas-preprocessor to provide something
> that can be digested by the iOS ARM assembler. It may be a good
> idea to report this issue to the developers of gas-preprocessor
> and ask for a piece of advice.
>  
> --  
> Best regards,
> Siarhei Siamashka
>  
>  

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

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

After spending a couple of hours on this, during which time I developed 
a new loathing for clang (I am already not a fan, after discovering that 
libjpeg-turbo generally performs 20% slower when built with it, and 
after many months, Apple has still not even commented on that issue.)  I 
concur that this seems to be an issue with gas-preprocessor.pl.  I 
encounter exactly the same error when using the following build procedure:

sudo xcode-select --switch /Applications/Xcode50.app
export 
IOS_PLATFORMDIR="/Applications/Xcode50.app/Contents/Developer/Platforms/iPhoneOS.platform"
export IOS_SYSROOT="$IOS_PLATFORMDIR/Developer/SDKs/iPhoneOS7.0.sdk"
export IOS_GCC=`xcrun -f clang`
export IOS_CFLAGS='-arch armv7s'
mkdir ios7
cd ios7
sh ../configure   --host arm-apple-darwin10 --enable-static 
--disable-shared CC="$IOS_GCC" LD="$IOS_GCC" CFLAGS="-isysroot 
$IOS_SYSROOT -O3 $IOS_CFLAGS" LDFLAGS="-isysroot $IOS_SYSROOT $IOS_CFLAGS"


On 1/18/14 5:15 PM, Pol-Online wrote:
> Hi,
>
> I’ve been trying to compile libturbo-jpeg for iOS devices with Xcode 5 /
> iOS 7 for some time but without success as it fails on the NEON
> instructions. I used to do it without problem with Xcode 4.x / iOS 6.
> I’m compiling the library on a completely stock OS X with just Xcode and
> developer command line tools installed on top of it.
>
> I found this old
> thread http://sourceforge.net/mailarchive/message.php?msg_id=30462917
> and tried the autoreconf tip, but it doesn’t fix the issue.
>
> Here’s the build script I use:
> https://gist.github.com/swisspol/8498104
>
> And here’s the full output:
> https://gist.github.com/swisspol/8498120
>
> With the failure part here:
>
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
> Making all in java
> echo timestamp > classnoinst.stamp
> Making all in simd
> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -E -I.. -I../simd
> ./jsimdcfg.inc.h | /usr/bin/grep -E "^[\;%]|^\ %" | sed
> 's%_cpp_protection_%%' | sed 's@% define@%define@g' > jsimdcfg.inc
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
> /bin/sh ../libtool  --tag=CC   --mode=compile
> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H
> -I. -I..  -I..  -O3 -arch armv7 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
>   -O3 -arch armv7 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> -miphoneos-version-min=5.0 -MT jsimd_arm.lo -MD -MP -MF
> .deps/jsimd_arm.Tpo -c -o jsimd_arm.lo jsimd_arm.c
> /bin/sh ../libtool    --mode=compile gas-preprocessor.pl
> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H
> -I. -I..  -I..  -O3 -arch armv7 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
>   -O3 -arch armv7 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> -miphoneos-version-min=5.0 -MT jsimd_arm_neon.lo -MD -MP -MF
> .deps/jsimd_arm_neon.Tpo -c -o jsimd_arm_neon.lo jsimd_arm_neon.S
> libtool: compile:
>   /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H
> -I. -I.. -I.. -O3 -arch armv7 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> -O3 -arch armv7 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> -miphoneos-version-min=5.0 -MT jsimd_arm.lo -MD -MP -MF
> .deps/jsimd_arm.Tpo -c jsimd_arm.c -o jsimd_arm.o
> libtool: compile:  gas-preprocessor.pl
> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H
> -I. -I.. -I.. -O3 -arch armv7 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> -O3 -arch armv7 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> -miphoneos-version-min=5.0 -MT jsimd_arm_neon.lo -MD -MP -MF
> .deps/jsimd_arm_neon.Tpo -c jsimd_arm_neon.S -o jsimd_arm_neon.o
> mv -f .deps/jsimd_arm.Tpo .deps/jsimd_arm.Plo
> clang: warning: argument unused during compilation: '-D HAVE_CONFIG_H'
> clang: warning: argument unused during compilation: '-I .'
> clang: warning: argument unused during compilation: '-I ..'
> clang: warning: argument unused during compilation: '-I ..'
> clang: warning: argument unused during compilation: '-MT jsimd_arm_neon.lo'
> clang: warning: argument unused during compilation: '-MD'
> clang: warning: argument unused during compilation: '-MP'
> clang: warning: argument unused during compilation: '-MF
> .deps/jsimd_arm_neon.Tpo'
> jsimd_arm_neon.S:270:16: error: invalid operand for instruction
>        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 1 * 8))]
>                 ^
> jsimd_arm_neon.S:276:16: error: invalid operand for instruction
>        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 2 * 8))]
>                 ^
> jsimd_arm_neon.S:283:16: error: invalid operand for instruction
>        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 3 * 8))]
>                 ^
> jsimd_arm_neon.S:291:16: error: invalid operand for instruction
>        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 4 * 8))]
>                 ^
> jsimd_arm_neon.S:299:16: error: invalid operand for instruction
>        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 5 * 8))]
>                 ^
> jsimd_arm_neon.S:306:16: error: invalid operand for instruction
>        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 6 * 8))]
>                 ^
> jsimd_arm_neon.S:313:16: error: invalid operand for instruction
>        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 7 * 8))]
>                 ^
> jsimd_arm_neon.S:321:16: error: invalid operand for instruction
>        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 0 * 8))]
>                 ^
> make[3]: *** [jsimd_arm_neon.lo] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
>
> Any help appreciated!
>
> PS: I understand one can grab the precompiled binaries from sourceforge,
> but I like to compile it myself and slightly customize it.
>
> PS 2: I also maintain a project on GitHub with ready-to-use build script
> for various popular open-source libraries on OS X /
> iOS: https://github.com/swisspol/Libraries. I’ll update the
> libjpeg-turbo one as soon as I can make it work again.
>
> -Pol
>
> ________________________________
> Pol-Online
> in...@po... <mailto:in...@po...>
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[George K. <gwk...@gm...>]

I never got this to work either; please do let us know if you have any
success!


On Tue, Jan 21, 2014 at 5:57 PM, DRC <dco...@us...>wrote:

> After spending a couple of hours on this, during which time I developed
> a new loathing for clang (I am already not a fan, after discovering that
> libjpeg-turbo generally performs 20% slower when built with it, and
> after many months, Apple has still not even commented on that issue.)  I
> concur that this seems to be an issue with gas-preprocessor.pl.  I
> encounter exactly the same error when using the following build procedure:
>
> sudo xcode-select --switch /Applications/Xcode50.app
> export
>
> IOS_PLATFORMDIR="/Applications/Xcode50.app/Contents/Developer/Platforms/iPhoneOS.platform"
> export IOS_SYSROOT="$IOS_PLATFORMDIR/Developer/SDKs/iPhoneOS7.0.sdk"
> export IOS_GCC=`xcrun -f clang`
> export IOS_CFLAGS='-arch armv7s'
> mkdir ios7
> cd ios7
> sh ../configure   --host arm-apple-darwin10 --enable-static
> --disable-shared CC="$IOS_GCC" LD="$IOS_GCC" CFLAGS="-isysroot
> $IOS_SYSROOT -O3 $IOS_CFLAGS" LDFLAGS="-isysroot $IOS_SYSROOT $IOS_CFLAGS"
>
>
> On 1/18/14 5:15 PM, Pol-Online wrote:
> > Hi,
> >
> > I've been trying to compile libturbo-jpeg for iOS devices with Xcode 5 /
> > iOS 7 for some time but without success as it fails on the NEON
> > instructions. I used to do it without problem with Xcode 4.x / iOS 6.
> > I'm compiling the library on a completely stock OS X with just Xcode and
> > developer command line tools installed on top of it.
> >
> > I found this old
> > thread http://sourceforge.net/mailarchive/message.php?msg_id=30462917
> > and tried the autoreconf tip, but it doesn't fix the issue.
> >
> > Here's the build script I use:
> > https://gist.github.com/swisspol/8498104
> >
> > And here's the full output:
> > https://gist.github.com/swisspol/8498120
> >
> > With the failure part here:
> >
> > /Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
> > Making all in java
> > echo timestamp > classnoinst.stamp
> > Making all in simd
> > /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -E -I.. -I../simd
> > ./jsimdcfg.inc.h | /usr/bin/grep -E "^[\;%]|^\ %" | sed
> > 's%_cpp_protection_%%' | sed 's@% define@%define@g' > jsimdcfg.inc
> > /Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
> > /bin/sh ../libtool  --tag=CC   --mode=compile
> > /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H
> > -I. -I..  -I..  -O3 -arch armv7 -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> >   -O3 -arch armv7 -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> > -miphoneos-version-min=5.0 -MT jsimd_arm.lo -MD -MP -MF
> > .deps/jsimd_arm.Tpo -c -o jsimd_arm.lo jsimd_arm.c
> > /bin/sh ../libtool    --mode=compile gas-preprocessor.pl
> > /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H
> > -I. -I..  -I..  -O3 -arch armv7 -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> >   -O3 -arch armv7 -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> > -miphoneos-version-min=5.0 -MT jsimd_arm_neon.lo -MD -MP -MF
> > .deps/jsimd_arm_neon.Tpo -c -o jsimd_arm_neon.lo jsimd_arm_neon.S
> > libtool: compile:
> >   /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H
> > -I. -I.. -I.. -O3 -arch armv7 -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> > -O3 -arch armv7 -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> > -miphoneos-version-min=5.0 -MT jsimd_arm.lo -MD -MP -MF
> > .deps/jsimd_arm.Tpo -c jsimd_arm.c -o jsimd_arm.o
> > libtool: compile:  gas-preprocessor.pl
> > /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -DHAVE_CONFIG_H
> > -I. -I.. -I.. -O3 -arch armv7 -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> > -O3 -arch armv7 -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
> > -miphoneos-version-min=5.0 -MT jsimd_arm_neon.lo -MD -MP -MF
> > .deps/jsimd_arm_neon.Tpo -c jsimd_arm_neon.S -o jsimd_arm_neon.o
> > mv -f .deps/jsimd_arm.Tpo .deps/jsimd_arm.Plo
> > clang: warning: argument unused during compilation: '-D HAVE_CONFIG_H'
> > clang: warning: argument unused during compilation: '-I .'
> > clang: warning: argument unused during compilation: '-I ..'
> > clang: warning: argument unused during compilation: '-I ..'
> > clang: warning: argument unused during compilation: '-MT
> jsimd_arm_neon.lo'
> > clang: warning: argument unused during compilation: '-MD'
> > clang: warning: argument unused during compilation: '-MP'
> > clang: warning: argument unused during compilation: '-MF
> > .deps/jsimd_arm_neon.Tpo'
> > jsimd_arm_neon.S:270:16: error: invalid operand for instruction
> >        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 1 * 8))]
> >                 ^
> > jsimd_arm_neon.S:276:16: error: invalid operand for instruction
> >        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 2 * 8))]
> >                 ^
> > jsimd_arm_neon.S:283:16: error: invalid operand for instruction
> >        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 3 * 8))]
> >                 ^
> > jsimd_arm_neon.S:291:16: error: invalid operand for instruction
> >        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 4 * 8))]
> >                 ^
> > jsimd_arm_neon.S:299:16: error: invalid operand for instruction
> >        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 5 * 8))]
> >                 ^
> > jsimd_arm_neon.S:306:16: error: invalid operand for instruction
> >        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 6 * 8))]
> >                 ^
> > jsimd_arm_neon.S:313:16: error: invalid operand for instruction
> >        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 7 * 8))]
> >                 ^
> > jsimd_arm_neon.S:321:16: error: invalid operand for instruction
> >        ldrd r4, [COEF_BLOCK, #(-96 + 2 * (4 + 0 * 8))]
> >                 ^
> > make[3]: *** [jsimd_arm_neon.lo] Error 1
> > make[2]: *** [all] Error 2
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2
> >
> >
> > Any help appreciated!
> >
> > PS: I understand one can grab the precompiled binaries from sourceforge,
> > but I like to compile it myself and slightly customize it.
> >
> > PS 2: I also maintain a project on GitHub with ready-to-use build script
> > for various popular open-source libraries on OS X /
> > iOS: https://github.com/swisspol/Libraries. I'll update the
> > libjpeg-turbo one as soon as I can make it work again.
> >
> > -Pol
> >
> > ________________________________
> > Pol-Online
> > in...@po... <mailto:in...@po...>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
> > Critical Workloads, Development Environments & Everything In Between.
> > Get a Quote or Start a Free Trial Today.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Libjpeg-turbo-users mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

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

Is there any reason why you guys have to use Xcode 5.0?  I mean, we know 
that the build works fine with Xcode 4.5.x and 4.6.x.  It's quite easy 
to install multiple versions of Xcode on the same system.  Just name 
Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as root) 
'xcode-select --switch /Applications/Xcode46.app' to use it from the 
command line.

The static libraries we ship in the official libjpeg-turbo OS X package 
also contain ARM v6, v7, and v7s architectures, so you should be able to 
link directly with those rather than building libjpeg-turbo yourself.

I treat libjpeg-turbo both as a project and a product.  As much as 
possible, I want it to be buildable by everyone, but I also don't want 
people to have to build it if they don't want to.


On 1/28/14 3:28 PM, George King wrote:
> I never got this to work either; please do let us know if you have any
> success!

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[Pol-Online <in...@po...>]

For me it’s mostly that Xcode 4.x is “deprecated” since 5.0 is out. I am fully aware some precompiled versions are available compatible with Xcode 5, which I am using in the mean time, but I like to build libraries myself, sometimes for “educational” purposes, sometimes for customization, which I can do with many libraries under Xcode5, except for libjpeg-turbo.

-Pol

________________________________
Pol-Online
in...@po... (mailto:in...@po...)


On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:

> Is there any reason why you guys have to use Xcode 5.0? I mean, we know  
> that the build works fine with Xcode 4.5.x and 4.6.x. It's quite easy  
> to install multiple versions of Xcode on the same system. Just name  
> Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as root)  
> 'xcode-select --switch /Applications/Xcode46.app' to use it from the  
> command line.
>  
> The static libraries we ship in the official libjpeg-turbo OS X package  
> also contain ARM v6, v7, and v7s architectures, so you should be able to  
> link directly with those rather than building libjpeg-turbo yourself.
>  
> I treat libjpeg-turbo both as a project and a product. As much as  
> possible, I want it to be buildable by everyone, but I also don't want  
> people to have to build it if they don't want to.
>  
>  
> On 1/28/14 3:28 PM, George King wrote:
> > I never got this to work either; please do let us know if you have any
> > success!
> >  
>  
>  
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable  
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li... (mailto:Lib...@li...)
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>  
>  

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

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

If you want to build an iOS binary of libjpeg-turbo from source for 
educational or tinkering purposes, then for the moment, you're going to 
have to use a "deprecated" version of Xcode.  I mean, I still use Xcode 
3.2.6 to produce the official binaries for this project, because that's 
the only way I can support OS X 10.5.  Asking others to use Xcode 4.6.x 
temporarily until the gas-preprocessor issues are worked out-- issues, 
by the way, that were caused by Apple completely pulling the rug out 
from underneath us vis-a-vis the compiler and assembler-- is not too 
much to ask, in my opinion.  Apple just unfortunately doesn't pay any 
heed to backward compatibility.  They want us to always use the latest & 
greatest O/S, so they try to enforce that by making it more and more 
difficult for developers to support older releases.  It forces open 
source developers, in particular, to be way more creative with build 
tools than we'd prefer to be.

I would like to support Xcode 5.0.  In order to make that happen, then 
gas-preprocessor.pl needs to be modified to work around a couple of 
issues with LLVM/clang.  The "invalid operand" issue is one of them. 
The other is that, when you pass "-x assembler" to clang, which is 
necessary when feeding it an assembly file via stdin like 
gas-preprocessor does, it seems to ignore some of the other arguments. 
The latter can be worked around in gas-preprocessor pretty easily, but 
the former seems to be a basic incompatibility between the assembly file 
and the new assembler.  The lines of code in question are unmodified 
relative to the original assembly file, so the presence of 
gas-preprocessor doesn't seem to be what's causing the failure.  The 
assembly code just won't assemble in clang.  That is not something I am 
capable of resolving, and note that I did spend about 4 hours trying 
various things in gas-preprocessor.


On 1/28/14 7:24 PM, Pol-Online wrote:
> For me it’s mostly that Xcode 4.x is “deprecated” since 5.0 is out. I am
> fully aware some precompiled versions are available compatible with
> Xcode 5, which I am using in the mean time, but I like to build
> libraries myself, sometimes for “educational” purposes, sometimes
> for customization, which I can do with many libraries under Xcode5,
> except for libjpeg-turbo.
>
> -Pol
>
> ________________________________
> Pol-Online
> in...@po... <mailto:in...@po...>
>
> On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
>
>> Is there any reason why you guys have to use Xcode 5.0? I mean, we know
>> that the build works fine with Xcode 4.5.x and 4.6.x. It's quite easy
>> to install multiple versions of Xcode on the same system. Just name
>> Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as root)
>> 'xcode-select --switch /Applications/Xcode46.app' to use it from the
>> command line.
>>
>> The static libraries we ship in the official libjpeg-turbo OS X package
>> also contain ARM v6, v7, and v7s architectures, so you should be able to
>> link directly with those rather than building libjpeg-turbo yourself.
>>
>> I treat libjpeg-turbo both as a project and a product. As much as
>> possible, I want it to be buildable by everyone, but I also don't want
>> people to have to build it if they don't want to.
>>
>>
>> On 1/28/14 3:28 PM, George King wrote:
>>> I never got this to work either; please do let us know if you have any
>>> success!

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[Pol-Online <in...@po...>]

Thanks for your help and efforts! I updated the issue I opened in GitHub against gas-preprocessor with your comments:
https://github.com/yuvi/gas-preprocessor/issues/26

-Pol

________________________________
Pol-Online
in...@po... (mailto:in...@po...)


On Wednesday, January 29, 2014 at 12:56 AM, DRC wrote:

> If you want to build an iOS binary of libjpeg-turbo from source for  
> educational or tinkering purposes, then for the moment, you're going to  
> have to use a "deprecated" version of Xcode. I mean, I still use Xcode  
> 3.2.6 to produce the official binaries for this project, because that's  
> the only way I can support OS X 10.5. Asking others to use Xcode 4.6.x  
> temporarily until the gas-preprocessor issues are worked out-- issues,  
> by the way, that were caused by Apple completely pulling the rug out  
> from underneath us vis-a-vis the compiler and assembler-- is not too  
> much to ask, in my opinion. Apple just unfortunately doesn't pay any  
> heed to backward compatibility. They want us to always use the latest &  
> greatest O/S, so they try to enforce that by making it more and more  
> difficult for developers to support older releases. It forces open  
> source developers, in particular, to be way more creative with build  
> tools than we'd prefer to be.
>  
> I would like to support Xcode 5.0. In order to make that happen, then  
> gas-preprocessor.pl (http://gas-preprocessor.pl) needs to be modified to work around a couple of  
> issues with LLVM/clang. The "invalid operand" issue is one of them.  
> The other is that, when you pass "-x assembler" to clang, which is  
> necessary when feeding it an assembly file via stdin like  
> gas-preprocessor does, it seems to ignore some of the other arguments.  
> The latter can be worked around in gas-preprocessor pretty easily, but  
> the former seems to be a basic incompatibility between the assembly file  
> and the new assembler. The lines of code in question are unmodified  
> relative to the original assembly file, so the presence of  
> gas-preprocessor doesn't seem to be what's causing the failure. The  
> assembly code just won't assemble in clang. That is not something I am  
> capable of resolving, and note that I did spend about 4 hours trying  
> various things in gas-preprocessor.
>  
>  
> On 1/28/14 7:24 PM, Pol-Online wrote:
> > For me it’s mostly that Xcode 4.x is “deprecated” since 5.0 is out. I am
> > fully aware some precompiled versions are available compatible with
> > Xcode 5, which I am using in the mean time, but I like to build
> > libraries myself, sometimes for “educational” purposes, sometimes
> > for customization, which I can do with many libraries under Xcode5,
> > except for libjpeg-turbo.
> >  
> > -Pol
> >  
> > ________________________________
> > Pol-Online
> > in...@po... <mailto:in...@po...>
> >  
> > On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
> >  
> > > Is there any reason why you guys have to use Xcode 5.0? I mean, we know
> > > that the build works fine with Xcode 4.5.x and 4.6.x. It's quite easy
> > > to install multiple versions of Xcode on the same system. Just name
> > > Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as root)
> > > 'xcode-select --switch /Applications/Xcode46.app' to use it from the
> > > command line.
> > >  
> > > The static libraries we ship in the official libjpeg-turbo OS X package
> > > also contain ARM v6, v7, and v7s architectures, so you should be able to
> > > link directly with those rather than building libjpeg-turbo yourself.
> > >  
> > > I treat libjpeg-turbo both as a project and a product. As much as
> > > possible, I want it to be buildable by everyone, but I also don't want
> > > people to have to build it if they don't want to.
> > >  
> > >  
> > > On 1/28/14 3:28 PM, George King wrote:
> > > > I never got this to work either; please do let us know if you have any
> > > > success!
> > > >  
> > >  
> > >  
> >  
> >  
>  
>  
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable  
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li... (mailto:Lib...@li...)
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>  
>  

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

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

I think I finally fixed this.  Two things are now required.  First, use 
my modified version of gas-preprocessor.pl:

https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/

This works around the Clang issue (bug) whereby it would ignore all 
other arguments if -x assembler is specified.  Now, gas-preprocessor.pl 
just creates a temporary file and executes the assembler with that 
temporary file, rather than trying to pipe its output into the assembler 
via stdin.  This eliminates the need to specify -x assembler, which 
works around the Clang bug.

Next, you need to add -no-integrated-as to your CFLAGS.

I have updated BUILDING.txt with the new instructions for Xcode 5.0. 
Please let me know if you run into any problems.


On 1/29/14 10:29 AM, Pol-Online wrote:
> Thanks for your help and efforts! I updated the issue I opened in GitHub
> against gas-preprocessor with your comments:
> https://github.com/yuvi/gas-preprocessor/issues/26
>
> -Pol
>
> ________________________________
> Pol-Online
> in...@po... <mailto:in...@po...>
>
> On Wednesday, January 29, 2014 at 12:56 AM, DRC wrote:
>
>> If you want to build an iOS binary of libjpeg-turbo from source for
>> educational or tinkering purposes, then for the moment, you're going to
>> have to use a "deprecated" version of Xcode. I mean, I still use Xcode
>> 3.2.6 to produce the official binaries for this project, because that's
>> the only way I can support OS X 10.5. Asking others to use Xcode 4.6.x
>> temporarily until the gas-preprocessor issues are worked out-- issues,
>> by the way, that were caused by Apple completely pulling the rug out
>> from underneath us vis-a-vis the compiler and assembler-- is not too
>> much to ask, in my opinion. Apple just unfortunately doesn't pay any
>> heed to backward compatibility. They want us to always use the latest &
>> greatest O/S, so they try to enforce that by making it more and more
>> difficult for developers to support older releases. It forces open
>> source developers, in particular, to be way more creative with build
>> tools than we'd prefer to be.
>>
>> I would like to support Xcode 5.0. In order to make that happen, then
>> gas-preprocessor.pl <http://gas-preprocessor.pl> needs to be modified
>> to work around a couple of
>> issues with LLVM/clang. The "invalid operand" issue is one of them.
>> The other is that, when you pass "-x assembler" to clang, which is
>> necessary when feeding it an assembly file via stdin like
>> gas-preprocessor does, it seems to ignore some of the other arguments.
>> The latter can be worked around in gas-preprocessor pretty easily, but
>> the former seems to be a basic incompatibility between the assembly file
>> and the new assembler. The lines of code in question are unmodified
>> relative to the original assembly file, so the presence of
>> gas-preprocessor doesn't seem to be what's causing the failure. The
>> assembly code just won't assemble in clang. That is not something I am
>> capable of resolving, and note that I did spend about 4 hours trying
>> various things in gas-preprocessor.
>>
>>
>> On 1/28/14 7:24 PM, Pol-Online wrote:
>>> For me it’s mostly that Xcode 4.x is “deprecated” since 5.0 is out. I am
>>> fully aware some precompiled versions are available compatible with
>>> Xcode 5, which I am using in the mean time, but I like to build
>>> libraries myself, sometimes for “educational” purposes, sometimes
>>> for customization, which I can do with many libraries under Xcode5,
>>> except for libjpeg-turbo.
>>>
>>> -Pol
>>>
>>> ________________________________
>>> Pol-Online
>>> in...@po... <mailto:in...@po...>
>>>
>>> On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
>>>
>>>> Is there any reason why you guys have to use Xcode 5.0? I mean, we know
>>>> that the build works fine with Xcode 4.5.x and 4.6.x. It's quite easy
>>>> to install multiple versions of Xcode on the same system. Just name
>>>> Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as root)
>>>> 'xcode-select --switch /Applications/Xcode46.app' to use it from the
>>>> command line.
>>>>
>>>> The static libraries we ship in the official libjpeg-turbo OS X package
>>>> also contain ARM v6, v7, and v7s architectures, so you should be able to
>>>> link directly with those rather than building libjpeg-turbo yourself.
>>>>
>>>> I treat libjpeg-turbo both as a project and a product. As much as
>>>> possible, I want it to be buildable by everyone, but I also don't want
>>>> people to have to build it if they don't want to.
>>>>
>>>>
>>>> On 1/28/14 3:28 PM, George King wrote:
>>>>> I never got this to work either; please do let us know if you have any
>>>>> success!

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[Pol-Online <in...@po...>]

Most impressive, thanks! I can confirm it builds fine for armv7 and the autoreconf hack is not needed anymore but I will do more tests. In the meantime, here’s my updated fully self contained test build script:  
https://gist.github.com/swisspol/8498104

-Pol

________________________________
Pol-Online
in...@po... (mailto:in...@po...)


On Wednesday, January 29, 2014 at 1:26 PM, DRC wrote:

> I think I finally fixed this. Two things are now required. First, use  
> my modified version of gas-preprocessor.pl (http://gas-preprocessor.pl):
>  
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/
>  
> This works around the Clang issue (bug) whereby it would ignore all  
> other arguments if -x assembler is specified. Now, gas-preprocessor.pl (http://gas-preprocessor.pl)  
> just creates a temporary file and executes the assembler with that  
> temporary file, rather than trying to pipe its output into the assembler  
> via stdin. This eliminates the need to specify -x assembler, which  
> works around the Clang bug.
>  
> Next, you need to add -no-integrated-as to your CFLAGS.
>  
> I have updated BUILDING.txt with the new instructions for Xcode 5.0.  
> Please let me know if you run into any problems.
>  
>  
> On 1/29/14 10:29 AM, Pol-Online wrote:
> > Thanks for your help and efforts! I updated the issue I opened in GitHub
> > against gas-preprocessor with your comments:
> > https://github.com/yuvi/gas-preprocessor/issues/26
> >  
> > -Pol
> >  
> > ________________________________
> > Pol-Online
> > in...@po... <mailto:in...@po...>
> >  
> > On Wednesday, January 29, 2014 at 12:56 AM, DRC wrote:
> >  
> > > If you want to build an iOS binary of libjpeg-turbo from source for
> > > educational or tinkering purposes, then for the moment, you're going to
> > > have to use a "deprecated" version of Xcode. I mean, I still use Xcode
> > > 3.2.6 to produce the official binaries for this project, because that's
> > > the only way I can support OS X 10.5. Asking others to use Xcode 4.6.x
> > > temporarily until the gas-preprocessor issues are worked out-- issues,
> > > by the way, that were caused by Apple completely pulling the rug out
> > > from underneath us vis-a-vis the compiler and assembler-- is not too
> > > much to ask, in my opinion. Apple just unfortunately doesn't pay any
> > > heed to backward compatibility. They want us to always use the latest &
> > > greatest O/S, so they try to enforce that by making it more and more
> > > difficult for developers to support older releases. It forces open
> > > source developers, in particular, to be way more creative with build
> > > tools than we'd prefer to be.
> > >  
> > > I would like to support Xcode 5.0. In order to make that happen, then
> > > gas-preprocessor.pl <http://gas-preprocessor.pl> needs to be modified
> > > to work around a couple of
> > > issues with LLVM/clang. The "invalid operand" issue is one of them.
> > > The other is that, when you pass "-x assembler" to clang, which is
> > > necessary when feeding it an assembly file via stdin like
> > > gas-preprocessor does, it seems to ignore some of the other arguments.
> > > The latter can be worked around in gas-preprocessor pretty easily, but
> > > the former seems to be a basic incompatibility between the assembly file
> > > and the new assembler. The lines of code in question are unmodified
> > > relative to the original assembly file, so the presence of
> > > gas-preprocessor doesn't seem to be what's causing the failure. The
> > > assembly code just won't assemble in clang. That is not something I am
> > > capable of resolving, and note that I did spend about 4 hours trying
> > > various things in gas-preprocessor.
> > >  
> > >  
> > > On 1/28/14 7:24 PM, Pol-Online wrote:
> > > > For me it’s mostly that Xcode 4.x is “deprecated” since 5.0 is out. I am
> > > > fully aware some precompiled versions are available compatible with
> > > > Xcode 5, which I am using in the mean time, but I like to build
> > > > libraries myself, sometimes for “educational” purposes, sometimes
> > > > for customization, which I can do with many libraries under Xcode5,
> > > > except for libjpeg-turbo.
> > > >  
> > > > -Pol
> > > >  
> > > > ________________________________
> > > > Pol-Online
> > > > in...@po... <mailto:in...@po...>
> > > >  
> > > > On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
> > > >  
> > > > > Is there any reason why you guys have to use Xcode 5.0? I mean, we know
> > > > > that the build works fine with Xcode 4.5.x and 4.6.x. It's quite easy
> > > > > to install multiple versions of Xcode on the same system. Just name
> > > > > Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as root)
> > > > > 'xcode-select --switch /Applications/Xcode46.app' to use it from the
> > > > > command line.
> > > > >  
> > > > > The static libraries we ship in the official libjpeg-turbo OS X package
> > > > > also contain ARM v6, v7, and v7s architectures, so you should be able to
> > > > > link directly with those rather than building libjpeg-turbo yourself.
> > > > >  
> > > > > I treat libjpeg-turbo both as a project and a product. As much as
> > > > > possible, I want it to be buildable by everyone, but I also don't want
> > > > > people to have to build it if they don't want to.
> > > > >  
> > > > >  
> > > > > On 1/28/14 3:28 PM, George King wrote:
> > > > > > I never got this to work either; please do let us know if you have any
> > > > > > success!
> > > > > >  
> > > > >  
> > > > >  
> > > >  
> > > >  
> > >  
> > >  
> >  
> >  
>  
>  
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable  
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li... (mailto:Lib...@li...)
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>  
>  

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[Pol-Online <in...@po...>]

I’ve done more testing and things appear to be working fine. For those of you who are interested, build script and pre-built libraries with Xcode5 / Clang are available here: https://github.com/swisspol/Libraries

Thanks again!  

-Pol

________________________________
Pol-Online
in...@po... (mailto:in...@po...)


On Wednesday, January 29, 2014 at 1:38 PM, Pol-Online wrote:

> Most impressive, thanks! I can confirm it builds fine for armv7 and the autoreconf hack is not needed anymore but I will do more tests. In the meantime, here’s my updated fully self contained test build script:  
> https://gist.github.com/swisspol/8498104
>  
> -Pol
>  
> ________________________________
> Pol-Online
> in...@po... (mailto:in...@po...)
>  
>  
> On Wednesday, January 29, 2014 at 1:26 PM, DRC wrote:
>  
> > I think I finally fixed this. Two things are now required. First, use  
> > my modified version of gas-preprocessor.pl (http://gas-preprocessor.pl):
> >  
> > https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/
> >  
> > This works around the Clang issue (bug) whereby it would ignore all  
> > other arguments if -x assembler is specified. Now, gas-preprocessor.pl (http://gas-preprocessor.pl)  
> > just creates a temporary file and executes the assembler with that  
> > temporary file, rather than trying to pipe its output into the assembler  
> > via stdin. This eliminates the need to specify -x assembler, which  
> > works around the Clang bug.
> >  
> > Next, you need to add -no-integrated-as to your CFLAGS.
> >  
> > I have updated BUILDING.txt with the new instructions for Xcode 5.0.  
> > Please let me know if you run into any problems.
> >  
> >  
> > On 1/29/14 10:29 AM, Pol-Online wrote:
> > > Thanks for your help and efforts! I updated the issue I opened in GitHub
> > > against gas-preprocessor with your comments:
> > > https://github.com/yuvi/gas-preprocessor/issues/26
> > >  
> > > -Pol
> > >  
> > > ________________________________
> > > Pol-Online
> > > in...@po... (mailto:in...@po...) <mailto:in...@po...>
> > >  
> > > On Wednesday, January 29, 2014 at 12:56 AM, DRC wrote:
> > >  
> > > > If you want to build an iOS binary of libjpeg-turbo from source for
> > > > educational or tinkering purposes, then for the moment, you're going to
> > > > have to use a "deprecated" version of Xcode. I mean, I still use Xcode
> > > > 3.2.6 to produce the official binaries for this project, because that's
> > > > the only way I can support OS X 10.5. Asking others to use Xcode 4.6.x
> > > > temporarily until the gas-preprocessor issues are worked out-- issues,
> > > > by the way, that were caused by Apple completely pulling the rug out
> > > > from underneath us vis-a-vis the compiler and assembler-- is not too
> > > > much to ask, in my opinion. Apple just unfortunately doesn't pay any
> > > > heed to backward compatibility. They want us to always use the latest &
> > > > greatest O/S, so they try to enforce that by making it more and more
> > > > difficult for developers to support older releases. It forces open
> > > > source developers, in particular, to be way more creative with build
> > > > tools than we'd prefer to be.
> > > >  
> > > > I would like to support Xcode 5.0. In order to make that happen, then
> > > > gas-preprocessor.pl (http://gas-preprocessor.pl) <http://gas-preprocessor.pl> needs to be modified
> > > > to work around a couple of
> > > > issues with LLVM/clang. The "invalid operand" issue is one of them.
> > > > The other is that, when you pass "-x assembler" to clang, which is
> > > > necessary when feeding it an assembly file via stdin like
> > > > gas-preprocessor does, it seems to ignore some of the other arguments.
> > > > The latter can be worked around in gas-preprocessor pretty easily, but
> > > > the former seems to be a basic incompatibility between the assembly file
> > > > and the new assembler. The lines of code in question are unmodified
> > > > relative to the original assembly file, so the presence of
> > > > gas-preprocessor doesn't seem to be what's causing the failure. The
> > > > assembly code just won't assemble in clang. That is not something I am
> > > > capable of resolving, and note that I did spend about 4 hours trying
> > > > various things in gas-preprocessor.
> > > >  
> > > >  
> > > > On 1/28/14 7:24 PM, Pol-Online wrote:
> > > > > For me it’s mostly that Xcode 4.x is “deprecated” since 5.0 is out. I am
> > > > > fully aware some precompiled versions are available compatible with
> > > > > Xcode 5, which I am using in the mean time, but I like to build
> > > > > libraries myself, sometimes for “educational” purposes, sometimes
> > > > > for customization, which I can do with many libraries under Xcode5,
> > > > > except for libjpeg-turbo.
> > > > >  
> > > > > -Pol
> > > > >  
> > > > > ________________________________
> > > > > Pol-Online
> > > > > in...@po... (mailto:in...@po...) <mailto:in...@po...>
> > > > >  
> > > > > On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
> > > > >  
> > > > > > Is there any reason why you guys have to use Xcode 5.0? I mean, we know
> > > > > > that the build works fine with Xcode 4.5.x and 4.6.x. It's quite easy
> > > > > > to install multiple versions of Xcode on the same system. Just name
> > > > > > Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as root)
> > > > > > 'xcode-select --switch /Applications/Xcode46.app' to use it from the
> > > > > > command line.
> > > > > >  
> > > > > > The static libraries we ship in the official libjpeg-turbo OS X package
> > > > > > also contain ARM v6, v7, and v7s architectures, so you should be able to
> > > > > > link directly with those rather than building libjpeg-turbo yourself.
> > > > > >  
> > > > > > I treat libjpeg-turbo both as a project and a product. As much as
> > > > > > possible, I want it to be buildable by everyone, but I also don't want
> > > > > > people to have to build it if they don't want to.
> > > > > >  
> > > > > >  
> > > > > > On 1/28/14 3:28 PM, George King wrote:
> > > > > > > I never got this to work either; please do let us know if you have any
> > > > > > > success!
> > > > > > >  
> > > > > >  
> > > > > >  
> > > > >  
> > > > >  
> > > >  
> > > >  
> > >  
> > >  
> >  
> >  
> > ------------------------------------------------------------------------------
> > WatchGuard Dimension instantly turns raw network data into actionable  
> > security intelligence. It gives you real-time visual feedback on key
> > security issues and trends. Skip the complicated setup - simply import
> > a virtual appliance and go from zero to informed in seconds.
> > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Libjpeg-turbo-users mailing list
> > Lib...@li... (mailto:Lib...@li...)
> > https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >  
> >  
> >  
>  
>  

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

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

I need to add one other thing, which is another reason why I recommended 
either building these libraries with GCC or using our pre-built 
binaries.  There is a known issue whereby libjpeg-turbo performs 
significantly worse when built with Clang vs. GCC.  Basically, pure GCC 
performs best, LLVM with the GCC front end performs less well, and LLVM 
with the Clang front end performs worst.  The difference is as much as 
20%.  Apple and the LLVM developers are aware of this, but nothing has 
happened on their end yet:

http://llvm.org/bugs/show_bug.cgi?id=16035

The official OS X/iOS binaries for libjpeg-turbo contain the following 
architectures:

i386, OS X 10.4+
x86-64, OS X 10.4+
32-bit armv6, iOS 4.3+
32-bit armv7, iOS 4.3+
32-bit armv7s, iOS 6.0+

There is no option to use pure GCC with ARM code, but I use LLVM/GCC in 
all of the ARM cases, so the binaries are as fast as possible.

Once we have a complete 64-bit ARM implementation, I intend to add a 
64-bit armv8 architecture to the official binaries as well.

It takes significant effort to create these multi-architecture binaries. 
  That effort is done on our end so you don't have to do it on your end. 
  My scripts for creating these binaries are fully open as well and can 
be found here: 
https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/buildscripts/libjpeg-turbo/

The official binaries I provide should be usable by any OS X or iOS app 
on any current OS X/iOS platform.  If they aren't, then I consider that 
to be a bug, and I'd like to hear about it.  Although I certainly want 
to enable people to build their own binaries, the official ones are the 
only ones that I support or recommend, because some of the performance 
and usability aspects of these binaries are a product of how they are built.


On 1/29/14 3:59 PM, Pol-Online wrote:
> I’ve done more testing and things appear to be working fine. For those
> of you who are interested, build script and pre-built libraries with
> Xcode5 / Clang are available here: https://github.com/swisspol/Libraries
>
> Thanks again!
>
> -Pol
>
> ________________________________
> Pol-Online
> in...@po... <mailto:in...@po...>
>
> On Wednesday, January 29, 2014 at 1:38 PM, Pol-Online wrote:
>
>> Most impressive, thanks! I can confirm it builds fine for armv7 and
>> the autoreconf hack is not needed anymore but I will do more tests. In
>> the meantime, here’s my updated fully self contained test build script:
>> https://gist.github.com/swisspol/8498104
>>
>> -Pol
>>
>> ________________________________
>> Pol-Online
>> in...@po... <mailto:in...@po...>
>>
>> On Wednesday, January 29, 2014 at 1:26 PM, DRC wrote:
>>
>>> I think I finally fixed this. Two things are now required. First, use
>>> my modified version of gas-preprocessor.pl <http://gas-preprocessor.pl>:
>>>
>>> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/
>>>
>>> This works around the Clang issue (bug) whereby it would ignore all
>>> other arguments if -x assembler is specified. Now,
>>> gas-preprocessor.pl <http://gas-preprocessor.pl>
>>> just creates a temporary file and executes the assembler with that
>>> temporary file, rather than trying to pipe its output into the assembler
>>> via stdin. This eliminates the need to specify -x assembler, which
>>> works around the Clang bug.
>>>
>>> Next, you need to add -no-integrated-as to your CFLAGS.
>>>
>>> I have updated BUILDING.txt with the new instructions for Xcode 5.0.
>>> Please let me know if you run into any problems.
>>>
>>>
>>> On 1/29/14 10:29 AM, Pol-Online wrote:
>>>> Thanks for your help and efforts! I updated the issue I opened in GitHub
>>>> against gas-preprocessor with your comments:
>>>> https://github.com/yuvi/gas-preprocessor/issues/26
>>>>
>>>> -Pol
>>>>
>>>> ________________________________
>>>> Pol-Online
>>>> in...@po... <mailto:in...@po...>
>>>> <mailto:in...@po...>
>>>>
>>>> On Wednesday, January 29, 2014 at 12:56 AM, DRC wrote:
>>>>
>>>>> If you want to build an iOS binary of libjpeg-turbo from source for
>>>>> educational or tinkering purposes, then for the moment, you're going to
>>>>> have to use a "deprecated" version of Xcode. I mean, I still use Xcode
>>>>> 3.2.6 to produce the official binaries for this project, because that's
>>>>> the only way I can support OS X 10.5. Asking others to use Xcode 4.6.x
>>>>> temporarily until the gas-preprocessor issues are worked out-- issues,
>>>>> by the way, that were caused by Apple completely pulling the rug out
>>>>> from underneath us vis-a-vis the compiler and assembler-- is not too
>>>>> much to ask, in my opinion. Apple just unfortunately doesn't pay any
>>>>> heed to backward compatibility. They want us to always use the latest &
>>>>> greatest O/S, so they try to enforce that by making it more and more
>>>>> difficult for developers to support older releases. It forces open
>>>>> source developers, in particular, to be way more creative with build
>>>>> tools than we'd prefer to be.
>>>>>
>>>>> I would like to support Xcode 5.0. In order to make that happen, then
>>>>> gas-preprocessor.pl <http://gas-preprocessor.pl>
>>>>> <http://gas-preprocessor.pl> needs to be modified
>>>>> to work around a couple of
>>>>> issues with LLVM/clang. The "invalid operand" issue is one of them.
>>>>> The other is that, when you pass "-x assembler" to clang, which is
>>>>> necessary when feeding it an assembly file via stdin like
>>>>> gas-preprocessor does, it seems to ignore some of the other arguments.
>>>>> The latter can be worked around in gas-preprocessor pretty easily, but
>>>>> the former seems to be a basic incompatibility between the assembly
>>>>> file
>>>>> and the new assembler. The lines of code in question are unmodified
>>>>> relative to the original assembly file, so the presence of
>>>>> gas-preprocessor doesn't seem to be what's causing the failure. The
>>>>> assembly code just won't assemble in clang. That is not something I am
>>>>> capable of resolving, and note that I did spend about 4 hours trying
>>>>> various things in gas-preprocessor.
>>>>>
>>>>>
>>>>> On 1/28/14 7:24 PM, Pol-Online wrote:
>>>>>> For me it’s mostly that Xcode 4.x is “deprecated” since 5.0 is
>>>>>> out. I am
>>>>>> fully aware some precompiled versions are available compatible with
>>>>>> Xcode 5, which I am using in the mean time, but I like to build
>>>>>> libraries myself, sometimes for “educational” purposes, sometimes
>>>>>> for customization, which I can do with many libraries under Xcode5,
>>>>>> except for libjpeg-turbo.
>>>>>>
>>>>>> -Pol
>>>>>>
>>>>>> ________________________________
>>>>>> Pol-Online
>>>>>> in...@po... <mailto:in...@po...>
>>>>>> <mailto:in...@po...>
>>>>>>
>>>>>> On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
>>>>>>
>>>>>>> Is there any reason why you guys have to use Xcode 5.0? I mean,
>>>>>>> we know
>>>>>>> that the build works fine with Xcode 4.5.x and 4.6.x. It's quite easy
>>>>>>> to install multiple versions of Xcode on the same system. Just name
>>>>>>> Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as root)
>>>>>>> 'xcode-select --switch /Applications/Xcode46.app' to use it from the
>>>>>>> command line.
>>>>>>>
>>>>>>> The static libraries we ship in the official libjpeg-turbo OS X
>>>>>>> package
>>>>>>> also contain ARM v6, v7, and v7s architectures, so you should be
>>>>>>> able to
>>>>>>> link directly with those rather than building libjpeg-turbo yourself.
>>>>>>>
>>>>>>> I treat libjpeg-turbo both as a project and a product. As much as
>>>>>>> possible, I want it to be buildable by everyone, but I also don't
>>>>>>> want
>>>>>>> people to have to build it if they don't want to.
>>>>>>>
>>>>>>>
>>>>>>> On 1/28/14 3:28 PM, George King wrote:
>>>>>>>> I never got this to work either; please do let us know if you
>>>>>>>> have any
>>>>>>>> success!
>>>
>>> ------------------------------------------------------------------------------
>>> WatchGuard Dimension instantly turns raw network data into actionable
>>> security intelligence. It gives you real-time visual feedback on key
>>> security issues and trends. Skip the complicated setup - simply import
>>> a virtual appliance and go from zero to informed in seconds.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Libjpeg-turbo-users mailing list
>>> Lib...@li...
>>> <mailto:Lib...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>>
>
>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[George K. <gwk...@gm...>]

First off, I want to extend a big thank you for the compatibility work that
DRC and everyone else has done to make this compile with clang. While I
recognize that there are performance issues with clang, the ability to
build libjpeg with the same toolchain that I use for all of my other work
is valuable, and I hope that we can maintain this compatibility.

Unfortunately, my build script broke after upgrading to Xcode 5.1. It
appears to be caused by the '-no-integrated-asm' flag, although I am not
familiar with the exact mechanism (I say this because I was passing that
flag to build scripts for several other libraries, sqlite3 and libpng among
others, and they both showed similar errors).

I would like to help debug this more, but I'm stumped by the fact that the
.s file referenced in the error is a temporary, and seems to be removed by
the time make exits. I think this is due to gas-preprocessor.pl, right?

Removing the -no-integrated-asm flag causes the older errors we saw in
jsimd_arm_neon.S; if I also add the --without-simd configuration flag then
the build succeeds.

I tried on both libjpeg-turbo 1.3.0 and 1.3.1. I am using the latest
gas-preprocessor.pl from
https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor; it
has not changed since I had this working. Note also that Xcode 5.1 contains
only the ios7.1 sdk, so that version number will need to be bumped in any
build setups.

Thanks in advance,
George

+ /Users/gwk/external/libjpeg-turbo-1.3.0/configure
--disable-dependency-tracking
--prefix=/Users/gwk/work/libqk/_tmp_build/ios-turbojpeg/armv7/install
--host=arm-apple-darwin10 --enable-static --disable-shared
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
LIBTOOL=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool
CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
LD=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
'CFLAGS=-O3 -no-integrated-as ' 'CPPFLAGS=-arch armv7
-miphoneos-version-min=7.0 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
-I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include'
'LDFLAGS= -arch armv7 -miphoneos-version-min=7.0 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
-L/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/lib'
--with-jpeg8 --without-simd


libtool: compile:
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7
-miphoneos-version-min=7.0 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
-I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
-O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcparam.c
-o jcparam.o
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:227:']'
expected -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:228:']'
expected -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:667:']'
expected -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:668:']'
expected -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:1093:']'
expected -- `vld1.64 {d16,d17},[r3:128]'
/bin/sh ./libtool  --tag=CC   --mode=compile
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0   -arch armv7
-miphoneos-version-min=7.0 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
-I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
 -O3 -no-integrated-as  -c -o jcphuff.lo
/Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [jcdctmgr.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
libtool: compile:
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7
-miphoneos-version-min=7.0 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
-I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
-O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c
-o jcphuff.o
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:386:']'
expected -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:387:']'
expected -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:397:']'
expected -- `vld1.64 {d18,d19},[r2:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:400:']'
expected -- `vld1.64 {d20,d21},[r2:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:402:']'
expected -- `vld1.64 {d24,d25},[r2:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:404:']'
expected -- `vld1.64 {d22,d23},[r2:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:406:']'
expected -- `vld1.64 {d26,d27},[r2:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:408:']'
expected -- `vld1.64 {d28,d29},[r2:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:410:']'
expected -- `vld1.64 {d30,d31},[r2:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:412:']'
expected -- `vld1.64 {d16,d17},[r2:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:414:']'
expected -- `vst1.64 {d16,d17},[lr:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:415:']'
expected -- `vld1.64 {d16,d17},[r2:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:417:']'
expected -- `vst1.64 {d16,d17},[sp:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:429:']'
expected -- `vld1.64 {d16,d17},[r5:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:449:']'
expected -- `vld1.64 {d16,d17},[sp:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:466:']'
expected -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:467:']'
expected -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [jccolor.lo] Error 1
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1310:']'
expected -- `vld1.64 {d16,d17},[r1:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1441:']'
expected -- `vld1.64 {d16,d17},[r3:128]'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [jcparam.lo] Error 1
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1044:']'
expected -- `vst1.64 {d8,d9},[r4:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1088:']'
expected -- `vld1.32 {d16[0]},[r3:32]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1093:']'
expected -- `vld1.32 {d18[0]},[r1:32]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1768:']'
expected -- `vld1.64 {d8,d9},[r4:128]'
/var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1786:']'
expected -- `vld1.64 {d8,d9},[r4:128]'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [jcmarker.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2



On Wed, Jan 29, 2014 at 5:18 PM, DRC <dco...@us...>wrote:

> I need to add one other thing, which is another reason why I recommended
> either building these libraries with GCC or using our pre-built
> binaries.  There is a known issue whereby libjpeg-turbo performs
> significantly worse when built with Clang vs. GCC.  Basically, pure GCC
> performs best, LLVM with the GCC front end performs less well, and LLVM
> with the Clang front end performs worst.  The difference is as much as
> 20%.  Apple and the LLVM developers are aware of this, but nothing has
> happened on their end yet:
>
> http://llvm.org/bugs/show_bug.cgi?id=16035
>
> The official OS X/iOS binaries for libjpeg-turbo contain the following
> architectures:
>
> i386, OS X 10.4+
> x86-64, OS X 10.4+
> 32-bit armv6, iOS 4.3+
> 32-bit armv7, iOS 4.3+
> 32-bit armv7s, iOS 6.0+
>
> There is no option to use pure GCC with ARM code, but I use LLVM/GCC in
> all of the ARM cases, so the binaries are as fast as possible.
>
> Once we have a complete 64-bit ARM implementation, I intend to add a
> 64-bit armv8 architecture to the official binaries as well.
>
> It takes significant effort to create these multi-architecture binaries.
>   That effort is done on our end so you don't have to do it on your end.
>   My scripts for creating these binaries are fully open as well and can
> be found here:
>
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/buildscripts/libjpeg-turbo/
>
> The official binaries I provide should be usable by any OS X or iOS app
> on any current OS X/iOS platform.  If they aren't, then I consider that
> to be a bug, and I'd like to hear about it.  Although I certainly want
> to enable people to build their own binaries, the official ones are the
> only ones that I support or recommend, because some of the performance
> and usability aspects of these binaries are a product of how they are
> built.
>
>
> On 1/29/14 3:59 PM, Pol-Online wrote:
> > I've done more testing and things appear to be working fine. For those
> > of you who are interested, build script and pre-built libraries with
> > Xcode5 / Clang are available here: https://github.com/swisspol/Libraries
> >
> > Thanks again!
> >
> > -Pol
> >
> > ________________________________
> > Pol-Online
> > in...@po... <mailto:in...@po...>
> >
> > On Wednesday, January 29, 2014 at 1:38 PM, Pol-Online wrote:
> >
> >> Most impressive, thanks! I can confirm it builds fine for armv7 and
> >> the autoreconf hack is not needed anymore but I will do more tests. In
> >> the meantime, here's my updated fully self contained test build script:
> >> https://gist.github.com/swisspol/8498104
> >>
> >> -Pol
> >>
> >> ________________________________
> >> Pol-Online
> >> in...@po... <mailto:in...@po...>
> >>
> >> On Wednesday, January 29, 2014 at 1:26 PM, DRC wrote:
> >>
> >>> I think I finally fixed this. Two things are now required. First, use
> >>> my modified version of gas-preprocessor.pl <http://gas-preprocessor.pl
> >:
> >>>
> >>>
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/
> >>>
> >>> This works around the Clang issue (bug) whereby it would ignore all
> >>> other arguments if -x assembler is specified. Now,
> >>> gas-preprocessor.pl <http://gas-preprocessor.pl>
> >>> just creates a temporary file and executes the assembler with that
> >>> temporary file, rather than trying to pipe its output into the
> assembler
> >>> via stdin. This eliminates the need to specify -x assembler, which
> >>> works around the Clang bug.
> >>>
> >>> Next, you need to add -no-integrated-as to your CFLAGS.
> >>>
> >>> I have updated BUILDING.txt with the new instructions for Xcode 5.0.
> >>> Please let me know if you run into any problems.
> >>>
> >>>
> >>> On 1/29/14 10:29 AM, Pol-Online wrote:
> >>>> Thanks for your help and efforts! I updated the issue I opened in
> GitHub
> >>>> against gas-preprocessor with your comments:
> >>>> https://github.com/yuvi/gas-preprocessor/issues/26
> >>>>
> >>>> -Pol
> >>>>
> >>>> ________________________________
> >>>> Pol-Online
> >>>> in...@po... <mailto:in...@po...>
> >>>> <mailto:in...@po...>
> >>>>
> >>>> On Wednesday, January 29, 2014 at 12:56 AM, DRC wrote:
> >>>>
> >>>>> If you want to build an iOS binary of libjpeg-turbo from source for
> >>>>> educational or tinkering purposes, then for the moment, you're going
> to
> >>>>> have to use a "deprecated" version of Xcode. I mean, I still use
> Xcode
> >>>>> 3.2.6 to produce the official binaries for this project, because
> that's
> >>>>> the only way I can support OS X 10.5. Asking others to use Xcode
> 4.6.x
> >>>>> temporarily until the gas-preprocessor issues are worked out--
> issues,
> >>>>> by the way, that were caused by Apple completely pulling the rug out
> >>>>> from underneath us vis-a-vis the compiler and assembler-- is not too
> >>>>> much to ask, in my opinion. Apple just unfortunately doesn't pay any
> >>>>> heed to backward compatibility. They want us to always use the
> latest &
> >>>>> greatest O/S, so they try to enforce that by making it more and more
> >>>>> difficult for developers to support older releases. It forces open
> >>>>> source developers, in particular, to be way more creative with build
> >>>>> tools than we'd prefer to be.
> >>>>>
> >>>>> I would like to support Xcode 5.0. In order to make that happen, then
> >>>>> gas-preprocessor.pl <http://gas-preprocessor.pl>
> >>>>> <http://gas-preprocessor.pl> needs to be modified
> >>>>> to work around a couple of
> >>>>> issues with LLVM/clang. The "invalid operand" issue is one of them.
> >>>>> The other is that, when you pass "-x assembler" to clang, which is
> >>>>> necessary when feeding it an assembly file via stdin like
> >>>>> gas-preprocessor does, it seems to ignore some of the other
> arguments.
> >>>>> The latter can be worked around in gas-preprocessor pretty easily,
> but
> >>>>> the former seems to be a basic incompatibility between the assembly
> >>>>> file
> >>>>> and the new assembler. The lines of code in question are unmodified
> >>>>> relative to the original assembly file, so the presence of
> >>>>> gas-preprocessor doesn't seem to be what's causing the failure. The
> >>>>> assembly code just won't assemble in clang. That is not something I
> am
> >>>>> capable of resolving, and note that I did spend about 4 hours trying
> >>>>> various things in gas-preprocessor.
> >>>>>
> >>>>>
> >>>>> On 1/28/14 7:24 PM, Pol-Online wrote:
> >>>>>> For me it's mostly that Xcode 4.x is "deprecated" since 5.0 is
> >>>>>> out. I am
> >>>>>> fully aware some precompiled versions are available compatible with
> >>>>>> Xcode 5, which I am using in the mean time, but I like to build
> >>>>>> libraries myself, sometimes for "educational" purposes, sometimes
> >>>>>> for customization, which I can do with many libraries under Xcode5,
> >>>>>> except for libjpeg-turbo.
> >>>>>>
> >>>>>> -Pol
> >>>>>>
> >>>>>> ________________________________
> >>>>>> Pol-Online
> >>>>>> in...@po... <mailto:in...@po...>
> >>>>>> <mailto:in...@po...>
> >>>>>>
> >>>>>> On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
> >>>>>>
> >>>>>>> Is there any reason why you guys have to use Xcode 5.0? I mean,
> >>>>>>> we know
> >>>>>>> that the build works fine with Xcode 4.5.x and 4.6.x. It's quite
> easy
> >>>>>>> to install multiple versions of Xcode on the same system. Just name
> >>>>>>> Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as
> root)
> >>>>>>> 'xcode-select --switch /Applications/Xcode46.app' to use it from
> the
> >>>>>>> command line.
> >>>>>>>
> >>>>>>> The static libraries we ship in the official libjpeg-turbo OS X
> >>>>>>> package
> >>>>>>> also contain ARM v6, v7, and v7s architectures, so you should be
> >>>>>>> able to
> >>>>>>> link directly with those rather than building libjpeg-turbo
> yourself.
> >>>>>>>
> >>>>>>> I treat libjpeg-turbo both as a project and a product. As much as
> >>>>>>> possible, I want it to be buildable by everyone, but I also don't
> >>>>>>> want
> >>>>>>> people to have to build it if they don't want to.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 1/28/14 3:28 PM, George King wrote:
> >>>>>>>> I never got this to work either; please do let us know if you
> >>>>>>>> have any
> >>>>>>>> success!
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> WatchGuard Dimension instantly turns raw network data into actionable
> >>> security intelligence. It gives you real-time visual feedback on key
> >>> security issues and trends. Skip the complicated setup - simply import
> >>> a virtual appliance and go from zero to informed in seconds.
> >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> >>> _______________________________________________
> >>> Libjpeg-turbo-users mailing list
> >>> Lib...@li...
> >>> <mailto:Lib...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > WatchGuard Dimension instantly turns raw network data into actionable
> > security intelligence. It gives you real-time visual feedback on key
> > security issues and trends.  Skip the complicated setup - simply import
> > a virtual appliance and go from zero to informed in seconds.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Libjpeg-turbo-users mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >
>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

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

<sigh>  You know, I used to complain about Microsoft, but despite the 
fact that Microsoft software is like French cars-- in that they copy 
nobody and nobody copies them-- at least MS provides really good 
backward compatibility with themselves.  I mean, I can still use the 
latest version of Visual C++ to produce a binary that runs on a 
20-year-old obsolete operating system (Window NT 3.x.)

I guess I have no choice but to fix this again, even though I already 
spent a lot of my time fixing it for XCode 5.0.  Really wishing Apple 
would just stop changing things for the sake of changing things.  If 
they were actually making things better, I wouldn't object, but here we 
sit still getting 20% worse performance out of their new compilers than 
their old compilers, and they are aware of it, and they just don't seem 
to care.  I wonder sometimes if they actually use their own development 
tools.  They certainly don't use them to build open source code, that's 
for sure.


On 3/26/14 2:26 PM, George King wrote:
> First off, I want to extend a big thank you for the compatibility work
> that DRC and everyone else has done to make this compile with clang.
> While I recognize that there are performance issues with clang, the
> ability to build libjpeg with the same toolchain that I use for all of
> my other work is valuable, and I hope that we can maintain this
> compatibility.
>
> Unfortunately, my build script broke after upgrading to Xcode 5.1. It
> appears to be caused by the '-no-integrated-asm' flag, although I am not
> familiar with the exact mechanism (I say this because I was passing that
> flag to build scripts for several other libraries, sqlite3 and libpng
> among others, and they both showed similar errors).
>
> I would like to help debug this more, but I'm stumped by the fact that
> the .s file referenced in the error is a temporary, and seems to be
> removed by the time make exits. I think this is due to
> gas-preprocessor.pl <http://gas-preprocessor.pl>, right?
>
> Removing the -no-integrated-asm flag causes the older errors we saw in
> jsimd_arm_neon.S; if I also add the --without-simd configuration flag
> then the build succeeds.
>
> I tried on both libjpeg-turbo 1.3.0 and 1.3.1. I am using the latest
> gas-preprocessor.pl <http://gas-preprocessor.pl> from
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor;
> it has not changed since I had this working. Note also that Xcode 5.1
> contains only the ios7.1 sdk, so that version number will need to be
> bumped in any build setups.
>
> Thanks in advance,
> George
>
> + /Users/gwk/external/libjpeg-turbo-1.3.0/configure
> --disable-dependency-tracking
> --prefix=/Users/gwk/work/libqk/_tmp_build/ios-turbojpeg/armv7/install
> --host=arm-apple-darwin10 --enable-static --disable-shared
> --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> LIBTOOL=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool
> CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
> LD=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
> 'CFLAGS=-O3 -no-integrated-as ' 'CPPFLAGS=-arch armv7
> -miphoneos-version-min=7.0 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include'
> 'LDFLAGS= -arch armv7 -miphoneos-version-min=7.0 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> -L/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/lib'
> --with-jpeg8 --without-simd
>
>
> libtool: compile:
>   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7 -miphoneos-version-min=7.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcparam.c -o jcparam.o
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:227:']'
> expected -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:228:']'
> expected -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:667:']'
> expected -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:668:']'
> expected -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:1093:']'
> expected -- `vld1.64 {d16,d17},[r3:128]'
> /bin/sh ./libtool  --tag=CC   --mode=compile
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0   -arch
> armv7 -miphoneos-version-min=7.0 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
>   -O3 -no-integrated-as  -c -o jcphuff.lo
> /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c
> clang: error: assembler command failed with exit code 1 (use -v to see
> invocation)
> make[2]: *** [jcdctmgr.lo] Error 1
> make[2]: *** Waiting for unfinished jobs....
> libtool: compile:
>   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7 -miphoneos-version-min=7.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c -o jcphuff.o
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:386:']' expected
> -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:387:']' expected
> -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:397:']' expected
> -- `vld1.64 {d18,d19},[r2:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:400:']' expected
> -- `vld1.64 {d20,d21},[r2:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:402:']' expected
> -- `vld1.64 {d24,d25},[r2:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:404:']' expected
> -- `vld1.64 {d22,d23},[r2:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:406:']' expected
> -- `vld1.64 {d26,d27},[r2:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:408:']' expected
> -- `vld1.64 {d28,d29},[r2:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:410:']' expected
> -- `vld1.64 {d30,d31},[r2:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:412:']' expected
> -- `vld1.64 {d16,d17},[r2:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:414:']' expected
> -- `vst1.64 {d16,d17},[lr:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:415:']' expected
> -- `vld1.64 {d16,d17},[r2:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:417:']' expected
> -- `vst1.64 {d16,d17},[sp:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:429:']' expected
> -- `vld1.64 {d16,d17},[r5:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:449:']' expected
> -- `vld1.64 {d16,d17},[sp:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:466:']' expected
> -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:467:']' expected
> -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
> clang: error: assembler command failed with exit code 1 (use -v to see
> invocation)
> make[2]: *** [jccolor.lo] Error 1
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1310:']'
> expected -- `vld1.64 {d16,d17},[r1:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1441:']'
> expected -- `vld1.64 {d16,d17},[r3:128]'
> clang: error: assembler command failed with exit code 1 (use -v to see
> invocation)
> make[2]: *** [jcparam.lo] Error 1
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1044:']'
> expected -- `vst1.64 {d8,d9},[r4:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1088:']'
> expected -- `vld1.32 {d16[0]},[r3:32]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1093:']'
> expected -- `vld1.32 {d18[0]},[r1:32]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1768:']'
> expected -- `vld1.64 {d8,d9},[r4:128]'
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1786:']'
> expected -- `vld1.64 {d8,d9},[r4:128]'
> clang: error: assembler command failed with exit code 1 (use -v to see
> invocation)
> make[2]: *** [jcmarker.lo] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
>
>
> On Wed, Jan 29, 2014 at 5:18 PM, DRC <dco...@us...
> <mailto:dco...@us...>> wrote:
>
>     I need to add one other thing, which is another reason why I recommended
>     either building these libraries with GCC or using our pre-built
>     binaries.  There is a known issue whereby libjpeg-turbo performs
>     significantly worse when built with Clang vs. GCC.  Basically, pure GCC
>     performs best, LLVM with the GCC front end performs less well, and LLVM
>     with the Clang front end performs worst.  The difference is as much as
>     20%.  Apple and the LLVM developers are aware of this, but nothing has
>     happened on their end yet:
>
>     http://llvm.org/bugs/show_bug.cgi?id=16035
>
>     The official OS X/iOS binaries for libjpeg-turbo contain the following
>     architectures:
>
>     i386, OS X 10.4+
>     x86-64, OS X 10.4+
>     32-bit armv6, iOS 4.3+
>     32-bit armv7, iOS 4.3+
>     32-bit armv7s, iOS 6.0+
>
>     There is no option to use pure GCC with ARM code, but I use LLVM/GCC in
>     all of the ARM cases, so the binaries are as fast as possible.
>
>     Once we have a complete 64-bit ARM implementation, I intend to add a
>     64-bit armv8 architecture to the official binaries as well.
>
>     It takes significant effort to create these multi-architecture binaries.
>        That effort is done on our end so you don't have to do it on your
>     end.
>        My scripts for creating these binaries are fully open as well and can
>     be found here:
>     https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/buildscripts/libjpeg-turbo/
>
>     The official binaries I provide should be usable by any OS X or iOS app
>     on any current OS X/iOS platform.  If they aren't, then I consider that
>     to be a bug, and I'd like to hear about it.  Although I certainly want
>     to enable people to build their own binaries, the official ones are the
>     only ones that I support or recommend, because some of the performance
>     and usability aspects of these binaries are a product of how they
>     are built.
>
>
>     On 1/29/14 3:59 PM, Pol-Online wrote:
>     > I’ve done more testing and things appear to be working fine. For those
>     > of you who are interested, build script and pre-built libraries with
>     > Xcode5 / Clang are available here:https://github.com/swisspol/Libraries
>     >
>     > Thanks again!
>     >
>     > -Pol
>     >
>     > ________________________________
>     > Pol-Online
>     >in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >
>     > On Wednesday, January 29, 2014 at 1:38 PM, Pol-Online wrote:
>     >
>     >> Most impressive, thanks! I can confirm it builds fine for armv7 and
>     >> the autoreconf hack is not needed anymore but I will do more tests. In
>     >> the meantime, here’s my updated fully self contained test build script:
>     >>https://gist.github.com/swisspol/8498104
>     >>
>     >> -Pol
>     >>
>     >> ________________________________
>     >> Pol-Online
>     >>in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >>
>     >> On Wednesday, January 29, 2014 at 1:26 PM, DRC wrote:
>     >>
>     >>> I think I finally fixed this. Two things are now required. First, use
>     >>> my modified version ofgas-preprocessor.pl <http://gas-preprocessor.pl>
>     <http://gas-preprocessor.pl>:
>     >>>
>     >>>https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/
>     >>>
>     >>> This works around the Clang issue (bug) whereby it would ignore all
>     >>> other arguments if -x assembler is specified. Now,
>     >>>gas-preprocessor.pl <http://gas-preprocessor.pl>
>     <http://gas-preprocessor.pl>
>     >>> just creates a temporary file and executes the assembler with that
>     >>> temporary file, rather than trying to pipe its output into the assembler
>     >>> via stdin. This eliminates the need to specify -x assembler, which
>     >>> works around the Clang bug.
>     >>>
>     >>> Next, you need to add -no-integrated-as to your CFLAGS.
>     >>>
>     >>> I have updated BUILDING.txt with the new instructions for Xcode 5.0.
>     >>> Please let me know if you run into any problems.
>     >>>
>     >>>
>     >>> On 1/29/14 10:29 AM, Pol-Online wrote:
>     >>>> Thanks for your help and efforts! I updated the issue I opened in GitHub
>     >>>> against gas-preprocessor with your comments:
>     >>>>https://github.com/yuvi/gas-preprocessor/issues/26
>     >>>>
>     >>>> -Pol
>     >>>>
>     >>>> ________________________________
>     >>>> Pol-Online
>     >>>>in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >>>> <mailto:in...@po... <mailto:in...@po...>>
>     >>>>
>     >>>> On Wednesday, January 29, 2014 at 12:56 AM, DRC wrote:
>     >>>>
>     >>>>> If you want to build an iOS binary of libjpeg-turbo from source for
>     >>>>> educational or tinkering purposes, then for the moment, you're going to
>     >>>>> have to use a "deprecated" version of Xcode. I mean, I still use Xcode
>     >>>>> 3.2.6 to produce the official binaries for this project, because that's
>     >>>>> the only way I can support OS X 10.5. Asking others to use Xcode 4.6.x
>     >>>>> temporarily until the gas-preprocessor issues are worked out-- issues,
>     >>>>> by the way, that were caused by Apple completely pulling the rug out
>     >>>>> from underneath us vis-a-vis the compiler and assembler-- is not too
>     >>>>> much to ask, in my opinion. Apple just unfortunately doesn't pay any
>     >>>>> heed to backward compatibility. They want us to always use the latest &
>     >>>>> greatest O/S, so they try to enforce that by making it more and more
>     >>>>> difficult for developers to support older releases. It forces open
>     >>>>> source developers, in particular, to be way more creative with build
>     >>>>> tools than we'd prefer to be.
>     >>>>>
>     >>>>> I would like to support Xcode 5.0. In order to make that happen, then
>     >>>>>gas-preprocessor.pl <http://gas-preprocessor.pl>
>     <http://gas-preprocessor.pl>
>     >>>>> <http://gas-preprocessor.pl> needs to be modified
>     >>>>> to work around a couple of
>     >>>>> issues with LLVM/clang. The "invalid operand" issue is one of them.
>     >>>>> The other is that, when you pass "-x assembler" to clang, which is
>     >>>>> necessary when feeding it an assembly file via stdin like
>     >>>>> gas-preprocessor does, it seems to ignore some of the other arguments.
>     >>>>> The latter can be worked around in gas-preprocessor pretty easily, but
>     >>>>> the former seems to be a basic incompatibility between the assembly
>     >>>>> file
>     >>>>> and the new assembler. The lines of code in question are unmodified
>     >>>>> relative to the original assembly file, so the presence of
>     >>>>> gas-preprocessor doesn't seem to be what's causing the failure. The
>     >>>>> assembly code just won't assemble in clang. That is not something I am
>     >>>>> capable of resolving, and note that I did spend about 4 hours trying
>     >>>>> various things in gas-preprocessor.
>     >>>>>
>     >>>>>
>     >>>>> On 1/28/14 7:24 PM, Pol-Online wrote:
>     >>>>>> For me it’s mostly that Xcode 4.x is “deprecated” since 5.0 is
>     >>>>>> out. I am
>     >>>>>> fully aware some precompiled versions are available compatible with
>     >>>>>> Xcode 5, which I am using in the mean time, but I like to build
>     >>>>>> libraries myself, sometimes for “educational” purposes, sometimes
>     >>>>>> for customization, which I can do with many libraries under Xcode5,
>     >>>>>> except for libjpeg-turbo.
>     >>>>>>
>     >>>>>> -Pol
>     >>>>>>
>     >>>>>> ________________________________
>     >>>>>> Pol-Online
>     >>>>>>in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >>>>>> <mailto:in...@po... <mailto:in...@po...>>
>     >>>>>>
>     >>>>>> On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
>     >>>>>>
>     >>>>>>> Is there any reason why you guys have to use Xcode 5.0? I mean,
>     >>>>>>> we know
>     >>>>>>> that the build works fine with Xcode 4.5.x and 4.6.x. It's quite easy
>     >>>>>>> to install multiple versions of Xcode on the same system. Just name
>     >>>>>>> Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as root)
>     >>>>>>> 'xcode-select --switch /Applications/Xcode46.app' to use it from the
>     >>>>>>> command line.
>     >>>>>>>
>     >>>>>>> The static libraries we ship in the official libjpeg-turbo OS X
>     >>>>>>> package
>     >>>>>>> also contain ARM v6, v7, and v7s architectures, so you should be
>     >>>>>>> able to
>     >>>>>>> link directly with those rather than building libjpeg-turbo yourself.
>     >>>>>>>
>     >>>>>>> I treat libjpeg-turbo both as a project and a product. As much as
>     >>>>>>> possible, I want it to be buildable by everyone, but I also don't
>     >>>>>>> want
>     >>>>>>> people to have to build it if they don't want to.
>     >>>>>>>
>     >>>>>>>
>     >>>>>>> On 1/28/14 3:28 PM, George King wrote:
>     >>>>>>>> I never got this to work either; please do let us know if you
>     >>>>>>>> have any
>     >>>>>>>> success!
>     >>>
>     >>> ------------------------------------------------------------------------------
>     >>> WatchGuard Dimension instantly turns raw network data into actionable
>     >>> security intelligence. It gives you real-time visual feedback on key
>     >>> security issues and trends. Skip the complicated setup - simply import
>     >>> a virtual appliance and go from zero to informed in seconds.
>     >>>http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>     >>> _______________________________________________
>     >>> Libjpeg-turbo-users mailing list
>     >>>Lib...@li...
>     <mailto:Lib...@li...>
>     >>> <mailto:Lib...@li...
>     <mailto:Lib...@li...>>
>     >>>https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >>
>     >
>     >
>     >
>     > ------------------------------------------------------------------------------
>     > WatchGuard Dimension instantly turns raw network data into actionable
>     > security intelligence. It gives you real-time visual feedback on key
>     > security issues and trends.  Skip the complicated setup - simply import
>     > a virtual appliance and go from zero to informed in seconds.
>     >http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>     >
>     >
>     >
>     > _______________________________________________
>     > Libjpeg-turbo-users mailing list
>     >Lib...@li...
>     <mailto:Lib...@li...>
>     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >
>
>     ------------------------------------------------------------------------------
>     WatchGuard Dimension instantly turns raw network data into actionable
>     security intelligence. It gives you real-time visual feedback on key
>     security issues and trends.  Skip the complicated setup - simply import
>     a virtual appliance and go from zero to informed in seconds.
>     http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Libjpeg-turbo-users mailing list
>     Lib...@li...
>     <mailto:Lib...@li...>
>     https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
>
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[George K. <gwk...@gm...>]

I agree that this is frustrating. I have one other comment, although I
imagine this is far too much work to be immediately practical: libpng went
through a similar ordeal, and I never got the gas-preprocessor approach
working (although i think the final problem was related to symbol
prefixes). Instead, somebody contributed a patch that used the arm neon
intrinsics and all the ASM problems fell by the wayside. I'm not qualified
to judge this in the context of jpeg-turbo, much less contribute such a
patch, but it did provide an escape from the low-level tooling problems.



On Wed, Mar 26, 2014 at 4:49 PM, DRC <dco...@us...>wrote:

> <sigh>  You know, I used to complain about Microsoft, but despite the
> fact that Microsoft software is like French cars-- in that they copy
> nobody and nobody copies them-- at least MS provides really good
> backward compatibility with themselves.  I mean, I can still use the
> latest version of Visual C++ to produce a binary that runs on a
> 20-year-old obsolete operating system (Window NT 3.x.)
>
> I guess I have no choice but to fix this again, even though I already
> spent a lot of my time fixing it for XCode 5.0.  Really wishing Apple
> would just stop changing things for the sake of changing things.  If
> they were actually making things better, I wouldn't object, but here we
> sit still getting 20% worse performance out of their new compilers than
> their old compilers, and they are aware of it, and they just don't seem
> to care.  I wonder sometimes if they actually use their own development
> tools.  They certainly don't use them to build open source code, that's
> for sure.
>
>
> On 3/26/14 2:26 PM, George King wrote:
> > First off, I want to extend a big thank you for the compatibility work
> > that DRC and everyone else has done to make this compile with clang.
> > While I recognize that there are performance issues with clang, the
> > ability to build libjpeg with the same toolchain that I use for all of
> > my other work is valuable, and I hope that we can maintain this
> > compatibility.
> >
> > Unfortunately, my build script broke after upgrading to Xcode 5.1. It
> > appears to be caused by the '-no-integrated-asm' flag, although I am not
> > familiar with the exact mechanism (I say this because I was passing that
> > flag to build scripts for several other libraries, sqlite3 and libpng
> > among others, and they both showed similar errors).
> >
> > I would like to help debug this more, but I'm stumped by the fact that
> > the .s file referenced in the error is a temporary, and seems to be
> > removed by the time make exits. I think this is due to
> > gas-preprocessor.pl <http://gas-preprocessor.pl>, right?
> >
> > Removing the -no-integrated-asm flag causes the older errors we saw in
> > jsimd_arm_neon.S; if I also add the --without-simd configuration flag
> > then the build succeeds.
> >
> > I tried on both libjpeg-turbo 1.3.0 and 1.3.1. I am using the latest
> > gas-preprocessor.pl <http://gas-preprocessor.pl> from
> > https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor;
> > it has not changed since I had this working. Note also that Xcode 5.1
> > contains only the ios7.1 sdk, so that version number will need to be
> > bumped in any build setups.
> >
> > Thanks in advance,
> > George
> >
> > + /Users/gwk/external/libjpeg-turbo-1.3.0/configure
> > --disable-dependency-tracking
> > --prefix=/Users/gwk/work/libqk/_tmp_build/ios-turbojpeg/armv7/install
> > --host=arm-apple-darwin10 --enable-static --disable-shared
> >
> --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >
> LIBTOOL=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool
> >
> CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> >
> CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
> >
> LD=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
> > 'CFLAGS=-O3 -no-integrated-as ' 'CPPFLAGS=-arch armv7
> > -miphoneos-version-min=7.0 -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include'
> > 'LDFLAGS= -arch armv7 -miphoneos-version-min=7.0 -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >
> -L/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/lib'
> > --with-jpeg8 --without-simd
> >
> >
> > libtool: compile:
> >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7
> -miphoneos-version-min=7.0 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
> -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcparam.c
> -o jcparam.o
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:227:']'
> > expected -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:228:']'
> > expected -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:667:']'
> > expected -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:668:']'
> > expected -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:1093:']'
> > expected -- `vld1.64 {d16,d17},[r3:128]'
> > /bin/sh ./libtool  --tag=CC   --mode=compile
> >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> > -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0   -arch
> > armv7 -miphoneos-version-min=7.0 -isysroot
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
> >   -O3 -no-integrated-as  -c -o jcphuff.lo
> > /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c
> > clang: error: assembler command failed with exit code 1 (use -v to see
> > invocation)
> > make[2]: *** [jcdctmgr.lo] Error 1
> > make[2]: *** Waiting for unfinished jobs....
> > libtool: compile:
> >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7
> -miphoneos-version-min=7.0 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
> -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c
> -o jcphuff.o
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:386:']'
> expected
> > -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:387:']'
> expected
> > -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:397:']'
> expected
> > -- `vld1.64 {d18,d19},[r2:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:400:']'
> expected
> > -- `vld1.64 {d20,d21},[r2:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:402:']'
> expected
> > -- `vld1.64 {d24,d25},[r2:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:404:']'
> expected
> > -- `vld1.64 {d22,d23},[r2:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:406:']'
> expected
> > -- `vld1.64 {d26,d27},[r2:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:408:']'
> expected
> > -- `vld1.64 {d28,d29},[r2:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:410:']'
> expected
> > -- `vld1.64 {d30,d31},[r2:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:412:']'
> expected
> > -- `vld1.64 {d16,d17},[r2:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:414:']'
> expected
> > -- `vst1.64 {d16,d17},[lr:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:415:']'
> expected
> > -- `vld1.64 {d16,d17},[r2:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:417:']'
> expected
> > -- `vst1.64 {d16,d17},[sp:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:429:']'
> expected
> > -- `vld1.64 {d16,d17},[r5:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:449:']'
> expected
> > -- `vld1.64 {d16,d17},[sp:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:466:']'
> expected
> > -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:467:']'
> expected
> > -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
> > clang: error: assembler command failed with exit code 1 (use -v to see
> > invocation)
> > make[2]: *** [jccolor.lo] Error 1
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1310:']'
> > expected -- `vld1.64 {d16,d17},[r1:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1441:']'
> > expected -- `vld1.64 {d16,d17},[r3:128]'
> > clang: error: assembler command failed with exit code 1 (use -v to see
> > invocation)
> > make[2]: *** [jcparam.lo] Error 1
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1044:']'
> > expected -- `vst1.64 {d8,d9},[r4:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1088:']'
> > expected -- `vld1.32 {d16[0]},[r3:32]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1093:']'
> > expected -- `vld1.32 {d18[0]},[r1:32]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1768:']'
> > expected -- `vld1.64 {d8,d9},[r4:128]'
> >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1786:']'
> > expected -- `vld1.64 {d8,d9},[r4:128]'
> > clang: error: assembler command failed with exit code 1 (use -v to see
> > invocation)
> > make[2]: *** [jcmarker.lo] Error 1
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2
> >
> >
> >
> > On Wed, Jan 29, 2014 at 5:18 PM, DRC <dco...@us...
> > <mailto:dco...@us...>> wrote:
> >
> >     I need to add one other thing, which is another reason why I
> recommended
> >     either building these libraries with GCC or using our pre-built
> >     binaries.  There is a known issue whereby libjpeg-turbo performs
> >     significantly worse when built with Clang vs. GCC.  Basically, pure
> GCC
> >     performs best, LLVM with the GCC front end performs less well, and
> LLVM
> >     with the Clang front end performs worst.  The difference is as much
> as
> >     20%.  Apple and the LLVM developers are aware of this, but nothing
> has
> >     happened on their end yet:
> >
> >     http://llvm.org/bugs/show_bug.cgi?id=16035
> >
> >     The official OS X/iOS binaries for libjpeg-turbo contain the
> following
> >     architectures:
> >
> >     i386, OS X 10.4+
> >     x86-64, OS X 10.4+
> >     32-bit armv6, iOS 4.3+
> >     32-bit armv7, iOS 4.3+
> >     32-bit armv7s, iOS 6.0+
> >
> >     There is no option to use pure GCC with ARM code, but I use LLVM/GCC
> in
> >     all of the ARM cases, so the binaries are as fast as possible.
> >
> >     Once we have a complete 64-bit ARM implementation, I intend to add a
> >     64-bit armv8 architecture to the official binaries as well.
> >
> >     It takes significant effort to create these multi-architecture
> binaries.
> >        That effort is done on our end so you don't have to do it on your
> >     end.
> >        My scripts for creating these binaries are fully open as well and
> can
> >     be found here:
> >
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/buildscripts/libjpeg-turbo/
> >
> >     The official binaries I provide should be usable by any OS X or iOS
> app
> >     on any current OS X/iOS platform.  If they aren't, then I consider
> that
> >     to be a bug, and I'd like to hear about it.  Although I certainly
> want
> >     to enable people to build their own binaries, the official ones are
> the
> >     only ones that I support or recommend, because some of the
> performance
> >     and usability aspects of these binaries are a product of how they
> >     are built.
> >
> >
> >     On 1/29/14 3:59 PM, Pol-Online wrote:
> >     > I've done more testing and things appear to be working fine. For
> those
> >     > of you who are interested, build script and pre-built libraries
> with
> >     > Xcode5 / Clang are available here:
> https://github.com/swisspol/Libraries
> >     >
> >     > Thanks again!
> >     >
> >     > -Pol
> >     >
> >     > ________________________________
> >     > Pol-Online
> >     >in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >
> >     > On Wednesday, January 29, 2014 at 1:38 PM, Pol-Online wrote:
> >     >
> >     >> Most impressive, thanks! I can confirm it builds fine for armv7
> and
> >     >> the autoreconf hack is not needed anymore but I will do more
> tests. In
> >     >> the meantime, here's my updated fully self contained test build
> script:
> >     >>https://gist.github.com/swisspol/8498104
> >     >>
> >     >> -Pol
> >     >>
> >     >> ________________________________
> >     >> Pol-Online
> >     >>in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >>
> >     >> On Wednesday, January 29, 2014 at 1:26 PM, DRC wrote:
> >     >>
> >     >>> I think I finally fixed this. Two things are now required.
> First, use
> >     >>> my modified version ofgas-preprocessor.pl <
> http://gas-preprocessor.pl>
> >     <http://gas-preprocessor.pl>:
> >     >>>
> >     >>>
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/
> >     >>>
> >     >>> This works around the Clang issue (bug) whereby it would ignore
> all
> >     >>> other arguments if -x assembler is specified. Now,
> >     >>>gas-preprocessor.pl <http://gas-preprocessor.pl>
> >     <http://gas-preprocessor.pl>
> >     >>> just creates a temporary file and executes the assembler with
> that
> >     >>> temporary file, rather than trying to pipe its output into the
> assembler
> >     >>> via stdin. This eliminates the need to specify -x assembler,
> which
> >     >>> works around the Clang bug.
> >     >>>
> >     >>> Next, you need to add -no-integrated-as to your CFLAGS.
> >     >>>
> >     >>> I have updated BUILDING.txt with the new instructions for Xcode
> 5.0.
> >     >>> Please let me know if you run into any problems.
> >     >>>
> >     >>>
> >     >>> On 1/29/14 10:29 AM, Pol-Online wrote:
> >     >>>> Thanks for your help and efforts! I updated the issue I opened
> in GitHub
> >     >>>> against gas-preprocessor with your comments:
> >     >>>>https://github.com/yuvi/gas-preprocessor/issues/26
> >     >>>>
> >     >>>> -Pol
> >     >>>>
> >     >>>> ________________________________
> >     >>>> Pol-Online
> >     >>>>in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >>>> <mailto:in...@po... <mailto:in...@po...>>
> >     >>>>
> >     >>>> On Wednesday, January 29, 2014 at 12:56 AM, DRC wrote:
> >     >>>>
> >     >>>>> If you want to build an iOS binary of libjpeg-turbo from
> source for
> >     >>>>> educational or tinkering purposes, then for the moment, you're
> going to
> >     >>>>> have to use a "deprecated" version of Xcode. I mean, I still
> use Xcode
> >     >>>>> 3.2.6 to produce the official binaries for this project,
> because that's
> >     >>>>> the only way I can support OS X 10.5. Asking others to use
> Xcode 4.6.x
> >     >>>>> temporarily until the gas-preprocessor issues are worked out--
> issues,
> >     >>>>> by the way, that were caused by Apple completely pulling the
> rug out
> >     >>>>> from underneath us vis-a-vis the compiler and assembler-- is
> not too
> >     >>>>> much to ask, in my opinion. Apple just unfortunately doesn't
> pay any
> >     >>>>> heed to backward compatibility. They want us to always use the
> latest &
> >     >>>>> greatest O/S, so they try to enforce that by making it more
> and more
> >     >>>>> difficult for developers to support older releases. It forces
> open
> >     >>>>> source developers, in particular, to be way more creative with
> build
> >     >>>>> tools than we'd prefer to be.
> >     >>>>>
> >     >>>>> I would like to support Xcode 5.0. In order to make that
> happen, then
> >     >>>>>gas-preprocessor.pl <http://gas-preprocessor.pl>
> >     <http://gas-preprocessor.pl>
> >     >>>>> <http://gas-preprocessor.pl> needs to be modified
> >     >>>>> to work around a couple of
> >     >>>>> issues with LLVM/clang. The "invalid operand" issue is one of
> them.
> >     >>>>> The other is that, when you pass "-x assembler" to clang,
> which is
> >     >>>>> necessary when feeding it an assembly file via stdin like
> >     >>>>> gas-preprocessor does, it seems to ignore some of the other
> arguments.
> >     >>>>> The latter can be worked around in gas-preprocessor pretty
> easily, but
> >     >>>>> the former seems to be a basic incompatibility between the
> assembly
> >     >>>>> file
> >     >>>>> and the new assembler. The lines of code in question are
> unmodified
> >     >>>>> relative to the original assembly file, so the presence of
> >     >>>>> gas-preprocessor doesn't seem to be what's causing the
> failure. The
> >     >>>>> assembly code just won't assemble in clang. That is not
> something I am
> >     >>>>> capable of resolving, and note that I did spend about 4 hours
> trying
> >     >>>>> various things in gas-preprocessor.
> >     >>>>>
> >     >>>>>
> >     >>>>> On 1/28/14 7:24 PM, Pol-Online wrote:
> >     >>>>>> For me it's mostly that Xcode 4.x is "deprecated" since 5.0 is
> >     >>>>>> out. I am
> >     >>>>>> fully aware some precompiled versions are available
> compatible with
> >     >>>>>> Xcode 5, which I am using in the mean time, but I like to
> build
> >     >>>>>> libraries myself, sometimes for "educational" purposes,
> sometimes
> >     >>>>>> for customization, which I can do with many libraries under
> Xcode5,
> >     >>>>>> except for libjpeg-turbo.
> >     >>>>>>
> >     >>>>>> -Pol
> >     >>>>>>
> >     >>>>>> ________________________________
> >     >>>>>> Pol-Online
> >     >>>>>>in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >>>>>> <mailto:in...@po... <mailto:in...@po...>>
> >     >>>>>>
> >     >>>>>> On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
> >     >>>>>>
> >     >>>>>>> Is there any reason why you guys have to use Xcode 5.0? I
> mean,
> >     >>>>>>> we know
> >     >>>>>>> that the build works fine with Xcode 4.5.x and 4.6.x. It's
> quite easy
> >     >>>>>>> to install multiple versions of Xcode on the same system.
> Just name
> >     >>>>>>> Xcode 4.6 (for instance) /Applications/Xcode46.app and run
> (as root)
> >     >>>>>>> 'xcode-select --switch /Applications/Xcode46.app' to use it
> from the
> >     >>>>>>> command line.
> >     >>>>>>>
> >     >>>>>>> The static libraries we ship in the official libjpeg-turbo
> OS X
> >     >>>>>>> package
> >     >>>>>>> also contain ARM v6, v7, and v7s architectures, so you
> should be
> >     >>>>>>> able to
> >     >>>>>>> link directly with those rather than building libjpeg-turbo
> yourself.
> >     >>>>>>>
> >     >>>>>>> I treat libjpeg-turbo both as a project and a product. As
> much as
> >     >>>>>>> possible, I want it to be buildable by everyone, but I also
> don't
> >     >>>>>>> want
> >     >>>>>>> people to have to build it if they don't want to.
> >     >>>>>>>
> >     >>>>>>>
> >     >>>>>>> On 1/28/14 3:28 PM, George King wrote:
> >     >>>>>>>> I never got this to work either; please do let us know if
> you
> >     >>>>>>>> have any
> >     >>>>>>>> success!
> >     >>>
> >     >>>
> ------------------------------------------------------------------------------
> >     >>> WatchGuard Dimension instantly turns raw network data into
> actionable
> >     >>> security intelligence. It gives you real-time visual feedback on
> key
> >     >>> security issues and trends. Skip the complicated setup - simply
> import
> >     >>> a virtual appliance and go from zero to informed in seconds.
> >     >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> >     >>> _______________________________________________
> >     >>> Libjpeg-turbo-users mailing list
> >     >>>Lib...@li...
> >     <mailto:Lib...@li...>
> >     >>> <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>
> >     >>>https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >>
> >     >
> >     >
> >     >
> >     >
> ------------------------------------------------------------------------------
> >     > WatchGuard Dimension instantly turns raw network data into
> actionable
> >     > security intelligence. It gives you real-time visual feedback on
> key
> >     > security issues and trends.  Skip the complicated setup - simply
> import
> >     > a virtual appliance and go from zero to informed in seconds.
> >     >
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > Libjpeg-turbo-users mailing list
> >     >Lib...@li...
> >     <mailto:Lib...@li...>
> >     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >
> >
> >
> ------------------------------------------------------------------------------
> >     WatchGuard Dimension instantly turns raw network data into actionable
> >     security intelligence. It gives you real-time visual feedback on key
> >     security issues and trends.  Skip the complicated setup - simply
> import
> >     a virtual appliance and go from zero to informed in seconds.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> >     _______________________________________________
> >     Libjpeg-turbo-users mailing list
> >     Lib...@li...
> >     <mailto:Lib...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> >
> >
> >
> > _______________________________________________
> > Libjpeg-turbo-users mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

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

The ARM code is all contributed by Nokia and Linaro, so those 
organizations have no interest in iOS.  Initially, some iOS developers 
figured out how to take the libjpeg-turbo ARM code and make it build for 
iOS with gas-preprocessor.pl, but it has ultimately fallen to me to 
maintain the iOS builds, which has included figuring out how to 
integrate the ARM architectures into the existing OS X binaries, testing 
and documenting the procedures with various versions of Xcode, and more 
recently, hacking gas-preprocessor.pl so it works with Xcode 5.0.  100% 
of this work is pro bono, so really, unless someone steps up as a 
general sponsor of the effort-- that is, an organization who is willing 
to fund all of the work for iOS on an ongoing basis-- my goal is to 
spend as little time as possible on it.


On 3/26/14 5:10 PM, George King wrote:
> I agree that this is frustrating. I have one other comment, although I
> imagine this is far too much work to be immediately practical: libpng
> went through a similar ordeal, and I never got the gas-preprocessor
> approach working (although i think the final problem was related to
> symbol prefixes). Instead, somebody contributed a patch that used the
> arm neon intrinsics and all the ASM problems fell by the wayside. I'm
> not qualified to judge this in the context of jpeg-turbo, much less
> contribute such a patch, but it did provide an escape from the low-level
> tooling problems.
>
>
>
> On Wed, Mar 26, 2014 at 4:49 PM, DRC <dco...@us...
> <mailto:dco...@us...>> wrote:
>
>     <sigh>  You know, I used to complain about Microsoft, but despite the
>     fact that Microsoft software is like French cars-- in that they copy
>     nobody and nobody copies them-- at least MS provides really good
>     backward compatibility with themselves.  I mean, I can still use the
>     latest version of Visual C++ to produce a binary that runs on a
>     20-year-old obsolete operating system (Window NT 3.x.)
>
>     I guess I have no choice but to fix this again, even though I already
>     spent a lot of my time fixing it for XCode 5.0.  Really wishing Apple
>     would just stop changing things for the sake of changing things.  If
>     they were actually making things better, I wouldn't object, but here we
>     sit still getting 20% worse performance out of their new compilers than
>     their old compilers, and they are aware of it, and they just don't seem
>     to care.  I wonder sometimes if they actually use their own development
>     tools.  They certainly don't use them to build open source code, that's
>     for sure.

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

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

The latest version of BUILDING.txt in trunk and branches/1.3.x 
(http://svn.code.sf.net/p/libjpeg-turbo/code/trunk/BUILDING.txt) has an 
updated procedure that should now work with Xcode 5.1.

Basically, I had to move -no-integrated-as into CCASFLAGS so that it 
only applies to the assembler code.  I also streamlined the instructions 
somewhat.

Another note:  I guess I didn't realize that the iOS compilers have a 
backward compatibility mechanism (-miphoneos-version-min) that is 
similar to the one used by the OS X compilers (-mmacosx-version-min).  I 
have traditionally not trusted any particular version of the OS X SDK to 
produce proper binaries for an older version.  For instance, if you try 
to use the Mountain Lion SDK with -mmacosx-version-min=10.5, you'll 
technically get a Leopard-compatible binary, but the shared library 
dependencies will be off.  Given that libjpeg-turbo doesn't have any 
significant external dependencies, though, it should be possible to use 
-miphoneos-version-min to build a backward-compatible version of it for 
iOS (all the way back to 4.3) using the latest Xcode.  I'm curious to 
hear from others as to how well this actually works.


On 3/26/14 5:10 PM, George King wrote:
> I agree that this is frustrating. I have one other comment, although I
> imagine this is far too much work to be immediately practical: libpng
> went through a similar ordeal, and I never got the gas-preprocessor
> approach working (although i think the final problem was related to
> symbol prefixes). Instead, somebody contributed a patch that used the
> arm neon intrinsics and all the ASM problems fell by the wayside. I'm
> not qualified to judge this in the context of jpeg-turbo, much less
> contribute such a patch, but it did provide an escape from the low-level
> tooling problems.
>
>
>
> On Wed, Mar 26, 2014 at 4:49 PM, DRC <dco...@us...
> <mailto:dco...@us...>> wrote:
>
>     <sigh>  You know, I used to complain about Microsoft, but despite the
>     fact that Microsoft software is like French cars-- in that they copy
>     nobody and nobody copies them-- at least MS provides really good
>     backward compatibility with themselves.  I mean, I can still use the
>     latest version of Visual C++ to produce a binary that runs on a
>     20-year-old obsolete operating system (Window NT 3.x.)
>
>     I guess I have no choice but to fix this again, even though I already
>     spent a lot of my time fixing it for XCode 5.0.  Really wishing Apple
>     would just stop changing things for the sake of changing things.  If
>     they were actually making things better, I wouldn't object, but here we
>     sit still getting 20% worse performance out of their new compilers than
>     their old compilers, and they are aware of it, and they just don't seem
>     to care.  I wonder sometimes if they actually use their own development
>     tools.  They certainly don't use them to build open source code, that's
>     for sure.
>
>
>     On 3/26/14 2:26 PM, George King wrote:
>     > First off, I want to extend a big thank you for the compatibility work
>     > that DRC and everyone else has done to make this compile with clang.
>     > While I recognize that there are performance issues with clang, the
>     > ability to build libjpeg with the same toolchain that I use for all of
>     > my other work is valuable, and I hope that we can maintain this
>     > compatibility.
>     >
>     > Unfortunately, my build script broke after upgrading to Xcode 5.1. It
>     > appears to be caused by the '-no-integrated-asm' flag, although I am not
>     > familiar with the exact mechanism (I say this because I was passing that
>     > flag to build scripts for several other libraries, sqlite3 and libpng
>     > among others, and they both showed similar errors).
>     >
>     > I would like to help debug this more, but I'm stumped by the fact that
>     > the .s file referenced in the error is a temporary, and seems to be
>     > removed by the time make exits. I think this is due to
>     >gas-preprocessor.pl <http://gas-preprocessor.pl>
>     <http://gas-preprocessor.pl>, right?
>     >
>     > Removing the -no-integrated-asm flag causes the older errors we saw in
>     > jsimd_arm_neon.S; if I also add the --without-simd configuration flag
>     > then the build succeeds.
>     >
>     > I tried on both libjpeg-turbo 1.3.0 and 1.3.1. I am using the latest
>     >gas-preprocessor.pl <http://gas-preprocessor.pl>
>     <http://gas-preprocessor.pl> from
>     >https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor;
>     > it has not changed since I had this working. Note also that Xcode 5.1
>     > contains only the ios7.1 sdk, so that version number will need to be
>     > bumped in any build setups.
>     >
>     > Thanks in advance,
>     > George
>     >
>     > + /Users/gwk/external/libjpeg-turbo-1.3.0/configure
>     > --disable-dependency-tracking
>     > --prefix=/Users/gwk/work/libqk/_tmp_build/ios-turbojpeg/armv7/install
>     > --host=arm-apple-darwin10 --enable-static --disable-shared
>     > --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
>     > LIBTOOL=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool
>     > CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>     > CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
>     > LD=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
>     > 'CFLAGS=-O3 -no-integrated-as ' 'CPPFLAGS=-arch armv7
>     > -miphoneos-version-min=7.0 -isysroot
>     > /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
>     > -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include'
>     > 'LDFLAGS= -arch armv7 -miphoneos-version-min=7.0 -isysroot
>     > /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
>     > -L/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/lib'
>     > --with-jpeg8 --without-simd
>     >
>     >
>     > libtool: compile:
>     >   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7 -miphoneos-version-min=7.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcparam.c -o jcparam.o
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:227:']'
>     > expected -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:228:']'
>     > expected -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:667:']'
>     > expected -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:668:']'
>     > expected -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:1093:']'
>     > expected -- `vld1.64 {d16,d17},[r3:128]'
>     > /bin/sh ./libtool  --tag=CC   --mode=compile
>     > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>     > -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0   -arch
>     > armv7 -miphoneos-version-min=7.0 -isysroot
>     > /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
>     > -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
>     >   -O3 -no-integrated-as  -c -o jcphuff.lo
>     > /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c
>     > clang: error: assembler command failed with exit code 1 (use -v to see
>     > invocation)
>     > make[2]: *** [jcdctmgr.lo] Error 1
>     > make[2]: *** Waiting for unfinished jobs....
>     > libtool: compile:
>     >   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7 -miphoneos-version-min=7.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c -o jcphuff.o
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:386:']' expected
>     > -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:387:']' expected
>     > -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:397:']' expected
>     > -- `vld1.64 {d18,d19},[r2:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:400:']' expected
>     > -- `vld1.64 {d20,d21},[r2:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:402:']' expected
>     > -- `vld1.64 {d24,d25},[r2:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:404:']' expected
>     > -- `vld1.64 {d22,d23},[r2:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:406:']' expected
>     > -- `vld1.64 {d26,d27},[r2:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:408:']' expected
>     > -- `vld1.64 {d28,d29},[r2:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:410:']' expected
>     > -- `vld1.64 {d30,d31},[r2:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:412:']' expected
>     > -- `vld1.64 {d16,d17},[r2:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:414:']' expected
>     > -- `vst1.64 {d16,d17},[lr:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:415:']' expected
>     > -- `vld1.64 {d16,d17},[r2:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:417:']' expected
>     > -- `vst1.64 {d16,d17},[sp:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:429:']' expected
>     > -- `vld1.64 {d16,d17},[r5:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:449:']' expected
>     > -- `vld1.64 {d16,d17},[sp:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:466:']' expected
>     > -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:467:']' expected
>     > -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
>     > clang: error: assembler command failed with exit code 1 (use -v to see
>     > invocation)
>     > make[2]: *** [jccolor.lo] Error 1
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1310:']'
>     > expected -- `vld1.64 {d16,d17},[r1:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1441:']'
>     > expected -- `vld1.64 {d16,d17},[r3:128]'
>     > clang: error: assembler command failed with exit code 1 (use -v to see
>     > invocation)
>     > make[2]: *** [jcparam.lo] Error 1
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1044:']'
>     > expected -- `vst1.64 {d8,d9},[r4:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1088:']'
>     > expected -- `vld1.32 {d16[0]},[r3:32]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1093:']'
>     > expected -- `vld1.32 {d18[0]},[r1:32]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1768:']'
>     > expected -- `vld1.64 {d8,d9},[r4:128]'
>     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1786:']'
>     > expected -- `vld1.64 {d8,d9},[r4:128]'
>     > clang: error: assembler command failed with exit code 1 (use -v to see
>     > invocation)
>     > make[2]: *** [jcmarker.lo] Error 1
>     > make[1]: *** [all-recursive] Error 1
>     > make: *** [all] Error 2
>     >
>     >
>     >
>     > On Wed, Jan 29, 2014 at 5:18 PM, DRC <dco...@us...
>     <mailto:dco...@us...>
>     > <mailto:dco...@us...
>     <mailto:dco...@us...>>> wrote:
>     >
>     >     I need to add one other thing, which is another reason why I recommended
>     >     either building these libraries with GCC or using our pre-built
>     >     binaries.  There is a known issue whereby libjpeg-turbo performs
>     >     significantly worse when built with Clang vs. GCC.  Basically, pure GCC
>     >     performs best, LLVM with the GCC front end performs less well, and LLVM
>     >     with the Clang front end performs worst.  The difference is as much as
>     >     20%.  Apple and the LLVM developers are aware of this, but nothing has
>     >     happened on their end yet:
>     >
>     >http://llvm.org/bugs/show_bug.cgi?id=16035
>     >
>     >     The official OS X/iOS binaries for libjpeg-turbo contain the following
>     >     architectures:
>     >
>     >     i386, OS X 10.4+
>     >     x86-64, OS X 10.4+
>     >     32-bit armv6, iOS 4.3+
>     >     32-bit armv7, iOS 4.3+
>     >     32-bit armv7s, iOS 6.0+
>     >
>     >     There is no option to use pure GCC with ARM code, but I use LLVM/GCC in
>     >     all of the ARM cases, so the binaries are as fast as possible.
>     >
>     >     Once we have a complete 64-bit ARM implementation, I intend to add a
>     >     64-bit armv8 architecture to the official binaries as well.
>     >
>     >     It takes significant effort to create these multi-architecture binaries.
>     >        That effort is done on our end so you don't have to do it on your
>     >     end.
>     >        My scripts for creating these binaries are fully open as well and can
>     >     be found here:
>     >https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/buildscripts/libjpeg-turbo/
>     >
>     >     The official binaries I provide should be usable by any OS X or iOS app
>     >     on any current OS X/iOS platform.  If they aren't, then I consider that
>     >     to be a bug, and I'd like to hear about it.  Although I certainly want
>     >     to enable people to build their own binaries, the official ones are the
>     >     only ones that I support or recommend, because some of the performance
>     >     and usability aspects of these binaries are a product of how they
>     >     are built.
>     >
>     >
>     >     On 1/29/14 3:59 PM, Pol-Online wrote:
>     >     > I’ve done more testing and things appear to be working fine. For those
>     >     > of you who are interested, build script and pre-built libraries with
>     >     > Xcode5 / Clang are available here:https://github.com/swisspol/Libraries
>     >     >
>     >     > Thanks again!
>     >     >
>     >     > -Pol
>     >     >
>     >     > ________________________________
>     >     > Pol-Online
>     >     >in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>
>     >     >
>     >     > On Wednesday, January 29, 2014 at 1:38 PM, Pol-Online wrote:
>     >     >
>     >     >> Most impressive, thanks! I can confirm it builds fine for armv7 and
>     >     >> the autoreconf hack is not needed anymore but I will do more tests. In
>     >     >> the meantime, here’s my updated fully self contained test build script:
>     >     >>https://gist.github.com/swisspol/8498104
>     >     >>
>     >     >> -Pol
>     >     >>
>     >     >> ________________________________
>     >     >> Pol-Online
>     >     >>in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>
>     >     >>
>     >     >> On Wednesday, January 29, 2014 at 1:26 PM, DRC wrote:
>     >     >>
>     >     >>> I think I finally fixed this. Two things are now required. First, use
>     >     >>> my modified versionofgas-preprocessor.pl <http://ofgas-preprocessor.pl>
>     <http://gas-preprocessor.pl>
>     >     <http://gas-preprocessor.pl>:
>     >     >>>
>     >     >>>https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/
>     >     >>>
>     >     >>> This works around the Clang issue (bug) whereby it would ignore all
>     >     >>> other arguments if -x assembler is specified. Now,
>     >     >>>gas-preprocessor.pl <http://gas-preprocessor.pl>
>     <http://gas-preprocessor.pl>
>     >     <http://gas-preprocessor.pl>
>     >     >>> just creates a temporary file and executes the assembler with that
>     >     >>> temporary file, rather than trying to pipe its output into the assembler
>     >     >>> via stdin. This eliminates the need to specify -x assembler, which
>     >     >>> works around the Clang bug.
>     >     >>>
>     >     >>> Next, you need to add -no-integrated-as to your CFLAGS.
>     >     >>>
>     >     >>> I have updated BUILDING.txt with the new instructions for Xcode 5.0.
>     >     >>> Please let me know if you run into any problems.
>     >     >>>
>     >     >>>
>     >     >>> On 1/29/14 10:29 AM, Pol-Online wrote:
>     >     >>>> Thanks for your help and efforts! I updated the issue I opened in GitHub
>     >     >>>> against gas-preprocessor with your comments:
>     >     >>>>https://github.com/yuvi/gas-preprocessor/issues/26
>     >     >>>>
>     >     >>>> -Pol
>     >     >>>>
>     >     >>>> ________________________________
>     >     >>>> Pol-Online
>     >     >>>>in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>
>     >     >>>> <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>
>     >     >>>>
>     >     >>>> On Wednesday, January 29, 2014 at 12:56 AM, DRC wrote:
>     >     >>>>
>     >     >>>>> If you want to build an iOS binary of libjpeg-turbo from source for
>     >     >>>>> educational or tinkering purposes, then for the moment, you're going to
>     >     >>>>> have to use a "deprecated" version of Xcode. I mean, I still use Xcode
>     >     >>>>> 3.2.6 to produce the official binaries for this project, because that's
>     >     >>>>> the only way I can support OS X 10.5. Asking others to use Xcode 4.6.x
>     >     >>>>> temporarily until the gas-preprocessor issues are worked out-- issues,
>     >     >>>>> by the way, that were caused by Apple completely pulling the rug out
>     >     >>>>> from underneath us vis-a-vis the compiler and assembler-- is not too
>     >     >>>>> much to ask, in my opinion. Apple just unfortunately doesn't pay any
>     >     >>>>> heed to backward compatibility. They want us to always use the latest &
>     >     >>>>> greatest O/S, so they try to enforce that by making it more and more
>     >     >>>>> difficult for developers to support older releases. It forces open
>     >     >>>>> source developers, in particular, to be way more creative with build
>     >     >>>>> tools than we'd prefer to be.
>     >     >>>>>
>     >     >>>>> I would like to support Xcode 5.0. In order to make that happen, then
>     >     >>>>>gas-preprocessor.pl <http://gas-preprocessor.pl>
>     <http://gas-preprocessor.pl>
>     >     <http://gas-preprocessor.pl>
>     >     >>>>> <http://gas-preprocessor.pl> needs to be modified
>     >     >>>>> to work around a couple of
>     >     >>>>> issues with LLVM/clang. The "invalid operand" issue is one of them.
>     >     >>>>> The other is that, when you pass "-x assembler" to clang, which is
>     >     >>>>> necessary when feeding it an assembly file via stdin like
>     >     >>>>> gas-preprocessor does, it seems to ignore some of the other arguments.
>     >     >>>>> The latter can be worked around in gas-preprocessor pretty easily, but
>     >     >>>>> the former seems to be a basic incompatibility between the assembly
>     >     >>>>> file
>     >     >>>>> and the new assembler. The lines of code in question are unmodified
>     >     >>>>> relative to the original assembly file, so the presence of
>     >     >>>>> gas-preprocessor doesn't seem to be what's causing the failure. The
>     >     >>>>> assembly code just won't assemble in clang. That is not something I am
>     >     >>>>> capable of resolving, and note that I did spend about 4 hours trying
>     >     >>>>> various things in gas-preprocessor.
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> On 1/28/14 7:24 PM, Pol-Online wrote:
>     >     >>>>>> For me it’s mostly that Xcode 4.x is “deprecated” since 5.0 is
>     >     >>>>>> out. I am
>     >     >>>>>> fully aware some precompiled versions are available compatible with
>     >     >>>>>> Xcode 5, which I am using in the mean time, but I like to build
>     >     >>>>>> libraries myself, sometimes for “educational” purposes, sometimes
>     >     >>>>>> for customization, which I can do with many libraries under Xcode5,
>     >     >>>>>> except for libjpeg-turbo.
>     >     >>>>>>
>     >     >>>>>> -Pol
>     >     >>>>>>
>     >     >>>>>> ________________________________
>     >     >>>>>> Pol-Online
>     >     >>>>>>in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>
>     >     >>>>>> <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>
>     >     >>>>>>
>     >     >>>>>> On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
>     >     >>>>>>
>     >     >>>>>>> Is there any reason why you guys have to use Xcode 5.0? I mean,
>     >     >>>>>>> we know
>     >     >>>>>>> that the build works fine with Xcode 4.5.x and 4.6.x. It's quite easy
>     >     >>>>>>> to install multiple versions of Xcode on the same system. Just name
>     >     >>>>>>> Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as root)
>     >     >>>>>>> 'xcode-select --switch /Applications/Xcode46.app' to use it from the
>     >     >>>>>>> command line.
>     >     >>>>>>>
>     >     >>>>>>> The static libraries we ship in the official libjpeg-turbo OS X
>     >     >>>>>>> package
>     >     >>>>>>> also contain ARM v6, v7, and v7s architectures, so you should be
>     >     >>>>>>> able to
>     >     >>>>>>> link directly with those rather than building libjpeg-turbo yourself.
>     >     >>>>>>>
>     >     >>>>>>> I treat libjpeg-turbo both as a project and a product. As much as
>     >     >>>>>>> possible, I want it to be buildable by everyone, but I also don't
>     >     >>>>>>> want
>     >     >>>>>>> people to have to build it if they don't want to.
>     >     >>>>>>>
>     >     >>>>>>>
>     >     >>>>>>> On 1/28/14 3:28 PM, George King wrote:
>     >     >>>>>>>> I never got this to work either; please do let us know if you
>     >     >>>>>>>> have any
>     >     >>>>>>>> success!
>     >     >>>
>     >     >>> ------------------------------------------------------------------------------
>     >     >>> WatchGuard Dimension instantly turns raw network data into actionable
>     >     >>> security intelligence. It gives you real-time visual feedback on key
>     >     >>> security issues and trends. Skip the complicated setup - simply import
>     >     >>> a virtual appliance and go from zero to informed in seconds.
>     >     >>>http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>     >     >>> _______________________________________________
>     >     >>> Libjpeg-turbo-users mailing list
>     >     >>>Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>
>     >     >>> <mailto:Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>>
>     >     >>>https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >     >>
>     >     >
>     >     >
>     >     >
>     >     > ------------------------------------------------------------------------------
>     >     > WatchGuard Dimension instantly turns raw network data into actionable
>     >     > security intelligence. It gives you real-time visual feedback on key
>     >     > security issues and trends.  Skip the complicated setup - simply import
>     >     > a virtual appliance and go from zero to informed in seconds.
>     >     >http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > Libjpeg-turbo-users mailing list
>     >     >Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>
>     >     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >     >
>     >
>     >     ------------------------------------------------------------------------------
>     >     WatchGuard Dimension instantly turns raw network data into actionable
>     >     security intelligence. It gives you real-time visual feedback on key
>     >     security issues and trends.  Skip the complicated setup - simply import
>     >     a virtual appliance and go from zero to informed in seconds.
>     >http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>     >     _______________________________________________
>     >     Libjpeg-turbo-users mailing list
>     >Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>
>     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >
>     >
>     >
>     >
>     > ------------------------------------------------------------------------------
>     > Learn Graph Databases - Download FREE O'Reilly Book
>     > "Graph Databases" is the definitive new guide to graph databases and their
>     > applications. Written by three acclaimed leaders in the field,
>     > this first edition is now available. Download your free book today!
>     >http://p.sf.net/sfu/13534_NeoTech
>     >
>     >
>     >
>     > _______________________________________________
>     > Libjpeg-turbo-users mailing list
>     >Lib...@li...
>     <mailto:Lib...@li...>
>     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Libjpeg-turbo-users mailing list
>     Lib...@li...
>     <mailto:Lib...@li...>
>     https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[George K. <gwk...@gm...>]

Thanks, your efforts are much appreciated. Moving the -no-integrated-as to
CCASFLAGS worked. Regarding -miphoneos-version-min, I am only targeting 7.0
so I can't verify but it sounds reasonable.



On Thu, Mar 27, 2014 at 12:00 AM, DRC <dco...@us...>wrote:

> The latest version of BUILDING.txt in trunk and branches/1.3.x
> (http://svn.code.sf.net/p/libjpeg-turbo/code/trunk/BUILDING.txt) has an
> updated procedure that should now work with Xcode 5.1.
>
> Basically, I had to move -no-integrated-as into CCASFLAGS so that it
> only applies to the assembler code.  I also streamlined the instructions
> somewhat.
>
> Another note:  I guess I didn't realize that the iOS compilers have a
> backward compatibility mechanism (-miphoneos-version-min) that is
> similar to the one used by the OS X compilers (-mmacosx-version-min).  I
> have traditionally not trusted any particular version of the OS X SDK to
> produce proper binaries for an older version.  For instance, if you try
> to use the Mountain Lion SDK with -mmacosx-version-min=10.5, you'll
> technically get a Leopard-compatible binary, but the shared library
> dependencies will be off.  Given that libjpeg-turbo doesn't have any
> significant external dependencies, though, it should be possible to use
> -miphoneos-version-min to build a backward-compatible version of it for
> iOS (all the way back to 4.3) using the latest Xcode.  I'm curious to
> hear from others as to how well this actually works.
>
>
> On 3/26/14 5:10 PM, George King wrote:
> > I agree that this is frustrating. I have one other comment, although I
> > imagine this is far too much work to be immediately practical: libpng
> > went through a similar ordeal, and I never got the gas-preprocessor
> > approach working (although i think the final problem was related to
> > symbol prefixes). Instead, somebody contributed a patch that used the
> > arm neon intrinsics and all the ASM problems fell by the wayside. I'm
> > not qualified to judge this in the context of jpeg-turbo, much less
> > contribute such a patch, but it did provide an escape from the low-level
> > tooling problems.
> >
> >
> >
> > On Wed, Mar 26, 2014 at 4:49 PM, DRC <dco...@us...
> > <mailto:dco...@us...>> wrote:
> >
> >     <sigh>  You know, I used to complain about Microsoft, but despite the
> >     fact that Microsoft software is like French cars-- in that they copy
> >     nobody and nobody copies them-- at least MS provides really good
> >     backward compatibility with themselves.  I mean, I can still use the
> >     latest version of Visual C++ to produce a binary that runs on a
> >     20-year-old obsolete operating system (Window NT 3.x.)
> >
> >     I guess I have no choice but to fix this again, even though I already
> >     spent a lot of my time fixing it for XCode 5.0.  Really wishing Apple
> >     would just stop changing things for the sake of changing things.  If
> >     they were actually making things better, I wouldn't object, but here
> we
> >     sit still getting 20% worse performance out of their new compilers
> than
> >     their old compilers, and they are aware of it, and they just don't
> seem
> >     to care.  I wonder sometimes if they actually use their own
> development
> >     tools.  They certainly don't use them to build open source code,
> that's
> >     for sure.
> >
> >
> >     On 3/26/14 2:26 PM, George King wrote:
> >     > First off, I want to extend a big thank you for the compatibility
> work
> >     > that DRC and everyone else has done to make this compile with
> clang.
> >     > While I recognize that there are performance issues with clang, the
> >     > ability to build libjpeg with the same toolchain that I use for
> all of
> >     > my other work is valuable, and I hope that we can maintain this
> >     > compatibility.
> >     >
> >     > Unfortunately, my build script broke after upgrading to Xcode 5.1.
> It
> >     > appears to be caused by the '-no-integrated-asm' flag, although I
> am not
> >     > familiar with the exact mechanism (I say this because I was
> passing that
> >     > flag to build scripts for several other libraries, sqlite3 and
> libpng
> >     > among others, and they both showed similar errors).
> >     >
> >     > I would like to help debug this more, but I'm stumped by the fact
> that
> >     > the .s file referenced in the error is a temporary, and seems to be
> >     > removed by the time make exits. I think this is due to
> >     >gas-preprocessor.pl <http://gas-preprocessor.pl>
> >     <http://gas-preprocessor.pl>, right?
> >     >
> >     > Removing the -no-integrated-asm flag causes the older errors we
> saw in
> >     > jsimd_arm_neon.S; if I also add the --without-simd configuration
> flag
> >     > then the build succeeds.
> >     >
> >     > I tried on both libjpeg-turbo 1.3.0 and 1.3.1. I am using the
> latest
> >     >gas-preprocessor.pl <http://gas-preprocessor.pl>
> >     <http://gas-preprocessor.pl> from
> >     >
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor;
> >     > it has not changed since I had this working. Note also that Xcode
> 5.1
> >     > contains only the ios7.1 sdk, so that version number will need to
> be
> >     > bumped in any build setups.
> >     >
> >     > Thanks in advance,
> >     > George
> >     >
> >     > + /Users/gwk/external/libjpeg-turbo-1.3.0/configure
> >     > --disable-dependency-tracking
> >     >
> --prefix=/Users/gwk/work/libqk/_tmp_build/ios-turbojpeg/armv7/install
> >     > --host=arm-apple-darwin10 --enable-static --disable-shared
> >     >
> --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >     >
> LIBTOOL=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool
> >     >
> CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> >     >
> CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
> >     >
> LD=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
> >     > 'CFLAGS=-O3 -no-integrated-as ' 'CPPFLAGS=-arch armv7
> >     > -miphoneos-version-min=7.0 -isysroot
> >     >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >     >
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include'
> >     > 'LDFLAGS= -arch armv7 -miphoneos-version-min=7.0 -isysroot
> >     >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >     >
> -L/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/lib'
> >     > --with-jpeg8 --without-simd
> >     >
> >     >
> >     > libtool: compile:
> >     >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7
> -miphoneos-version-min=7.0 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
> -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcparam.c
> -o jcparam.o
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:227:']'
> >     > expected -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:228:']'
> >     > expected -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:667:']'
> >     > expected -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:668:']'
> >     > expected -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:1093:']'
> >     > expected -- `vld1.64 {d16,d17},[r3:128]'
> >     > /bin/sh ./libtool  --tag=CC   --mode=compile
> >     >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> >     > -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0
> -arch
> >     > armv7 -miphoneos-version-min=7.0 -isysroot
> >     >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >     >
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
> >     >   -O3 -no-integrated-as  -c -o jcphuff.lo
> >     > /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c
> >     > clang: error: assembler command failed with exit code 1 (use -v to
> see
> >     > invocation)
> >     > make[2]: *** [jcdctmgr.lo] Error 1
> >     > make[2]: *** Waiting for unfinished jobs....
> >     > libtool: compile:
> >     >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7
> -miphoneos-version-min=7.0 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
> -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c
> -o jcphuff.o
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:386:']'
> expected
> >     > -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:387:']'
> expected
> >     > -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:397:']'
> expected
> >     > -- `vld1.64 {d18,d19},[r2:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:400:']'
> expected
> >     > -- `vld1.64 {d20,d21},[r2:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:402:']'
> expected
> >     > -- `vld1.64 {d24,d25},[r2:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:404:']'
> expected
> >     > -- `vld1.64 {d22,d23},[r2:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:406:']'
> expected
> >     > -- `vld1.64 {d26,d27},[r2:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:408:']'
> expected
> >     > -- `vld1.64 {d28,d29},[r2:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:410:']'
> expected
> >     > -- `vld1.64 {d30,d31},[r2:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:412:']'
> expected
> >     > -- `vld1.64 {d16,d17},[r2:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:414:']'
> expected
> >     > -- `vst1.64 {d16,d17},[lr:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:415:']'
> expected
> >     > -- `vld1.64 {d16,d17},[r2:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:417:']'
> expected
> >     > -- `vst1.64 {d16,d17},[sp:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:429:']'
> expected
> >     > -- `vld1.64 {d16,d17},[r5:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:449:']'
> expected
> >     > -- `vld1.64 {d16,d17},[sp:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:466:']'
> expected
> >     > -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:467:']'
> expected
> >     > -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
> >     > clang: error: assembler command failed with exit code 1 (use -v to
> see
> >     > invocation)
> >     > make[2]: *** [jccolor.lo] Error 1
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1310:']'
> >     > expected -- `vld1.64 {d16,d17},[r1:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1441:']'
> >     > expected -- `vld1.64 {d16,d17},[r3:128]'
> >     > clang: error: assembler command failed with exit code 1 (use -v to
> see
> >     > invocation)
> >     > make[2]: *** [jcparam.lo] Error 1
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1044:']'
> >     > expected -- `vst1.64 {d8,d9},[r4:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1088:']'
> >     > expected -- `vld1.32 {d16[0]},[r3:32]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1093:']'
> >     > expected -- `vld1.32 {d18[0]},[r1:32]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1768:']'
> >     > expected -- `vld1.64 {d8,d9},[r4:128]'
> >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1786:']'
> >     > expected -- `vld1.64 {d8,d9},[r4:128]'
> >     > clang: error: assembler command failed with exit code 1 (use -v to
> see
> >     > invocation)
> >     > make[2]: *** [jcmarker.lo] Error 1
> >     > make[1]: *** [all-recursive] Error 1
> >     > make: *** [all] Error 2
> >     >
> >     >
> >     >
> >     > On Wed, Jan 29, 2014 at 5:18 PM, DRC <
> dco...@us...
> >     <mailto:dco...@us...>
> >     > <mailto:dco...@us...
> >     <mailto:dco...@us...>>> wrote:
> >     >
> >     >     I need to add one other thing, which is another reason why I
> recommended
> >     >     either building these libraries with GCC or using our pre-built
> >     >     binaries.  There is a known issue whereby libjpeg-turbo
> performs
> >     >     significantly worse when built with Clang vs. GCC.  Basically,
> pure GCC
> >     >     performs best, LLVM with the GCC front end performs less well,
> and LLVM
> >     >     with the Clang front end performs worst.  The difference is as
> much as
> >     >     20%.  Apple and the LLVM developers are aware of this, but
> nothing has
> >     >     happened on their end yet:
> >     >
> >     >http://llvm.org/bugs/show_bug.cgi?id=16035
> >     >
> >     >     The official OS X/iOS binaries for libjpeg-turbo contain the
> following
> >     >     architectures:
> >     >
> >     >     i386, OS X 10.4+
> >     >     x86-64, OS X 10.4+
> >     >     32-bit armv6, iOS 4.3+
> >     >     32-bit armv7, iOS 4.3+
> >     >     32-bit armv7s, iOS 6.0+
> >     >
> >     >     There is no option to use pure GCC with ARM code, but I use
> LLVM/GCC in
> >     >     all of the ARM cases, so the binaries are as fast as possible.
> >     >
> >     >     Once we have a complete 64-bit ARM implementation, I intend to
> add a
> >     >     64-bit armv8 architecture to the official binaries as well.
> >     >
> >     >     It takes significant effort to create these multi-architecture
> binaries.
> >     >        That effort is done on our end so you don't have to do it
> on your
> >     >     end.
> >     >        My scripts for creating these binaries are fully open as
> well and can
> >     >     be found here:
> >     >
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/buildscripts/libjpeg-turbo/
> >     >
> >     >     The official binaries I provide should be usable by any OS X
> or iOS app
> >     >     on any current OS X/iOS platform.  If they aren't, then I
> consider that
> >     >     to be a bug, and I'd like to hear about it.  Although I
> certainly want
> >     >     to enable people to build their own binaries, the official
> ones are the
> >     >     only ones that I support or recommend, because some of the
> performance
> >     >     and usability aspects of these binaries are a product of how
> they
> >     >     are built.
> >     >
> >     >
> >     >     On 1/29/14 3:59 PM, Pol-Online wrote:
> >     >     > I've done more testing and things appear to be working fine.
> For those
> >     >     > of you who are interested, build script and pre-built
> libraries with
> >     >     > Xcode5 / Clang are available here:
> https://github.com/swisspol/Libraries
> >     >     >
> >     >     > Thanks again!
> >     >     >
> >     >     > -Pol
> >     >     >
> >     >     > ________________________________
> >     >     > Pol-Online
> >     >     >in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>
> >     >     >
> >     >     > On Wednesday, January 29, 2014 at 1:38 PM, Pol-Online wrote:
> >     >     >
> >     >     >> Most impressive, thanks! I can confirm it builds fine for
> armv7 and
> >     >     >> the autoreconf hack is not needed anymore but I will do
> more tests. In
> >     >     >> the meantime, here's my updated fully self contained test
> build script:
> >     >     >>https://gist.github.com/swisspol/8498104
> >     >     >>
> >     >     >> -Pol
> >     >     >>
> >     >     >> ________________________________
> >     >     >> Pol-Online
> >     >     >>in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>
> >     >     >>
> >     >     >> On Wednesday, January 29, 2014 at 1:26 PM, DRC wrote:
> >     >     >>
> >     >     >>> I think I finally fixed this. Two things are now required.
> First, use
> >     >     >>> my modified versionofgas-preprocessor.pl <
> http://ofgas-preprocessor.pl>
> >     <http://gas-preprocessor.pl>
> >     >     <http://gas-preprocessor.pl>:
> >     >     >>>
> >     >     >>>
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/
> >     >     >>>
> >     >     >>> This works around the Clang issue (bug) whereby it would
> ignore all
> >     >     >>> other arguments if -x assembler is specified. Now,
> >     >     >>>gas-preprocessor.pl <http://gas-preprocessor.pl>
> >     <http://gas-preprocessor.pl>
> >     >     <http://gas-preprocessor.pl>
> >     >     >>> just creates a temporary file and executes the assembler
> with that
> >     >     >>> temporary file, rather than trying to pipe its output into
> the assembler
> >     >     >>> via stdin. This eliminates the need to specify -x
> assembler, which
> >     >     >>> works around the Clang bug.
> >     >     >>>
> >     >     >>> Next, you need to add -no-integrated-as to your CFLAGS.
> >     >     >>>
> >     >     >>> I have updated BUILDING.txt with the new instructions for
> Xcode 5.0.
> >     >     >>> Please let me know if you run into any problems.
> >     >     >>>
> >     >     >>>
> >     >     >>> On 1/29/14 10:29 AM, Pol-Online wrote:
> >     >     >>>> Thanks for your help and efforts! I updated the issue I
> opened in GitHub
> >     >     >>>> against gas-preprocessor with your comments:
> >     >     >>>>https://github.com/yuvi/gas-preprocessor/issues/26
> >     >     >>>>
> >     >     >>>> -Pol
> >     >     >>>>
> >     >     >>>> ________________________________
> >     >     >>>> Pol-Online
> >     >     >>>>in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>
> >     >     >>>> <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>
> >     >     >>>>
> >     >     >>>> On Wednesday, January 29, 2014 at 12:56 AM, DRC wrote:
> >     >     >>>>
> >     >     >>>>> If you want to build an iOS binary of libjpeg-turbo from
> source for
> >     >     >>>>> educational or tinkering purposes, then for the moment,
> you're going to
> >     >     >>>>> have to use a "deprecated" version of Xcode. I mean, I
> still use Xcode
> >     >     >>>>> 3.2.6 to produce the official binaries for this project,
> because that's
> >     >     >>>>> the only way I can support OS X 10.5. Asking others to
> use Xcode 4.6.x
> >     >     >>>>> temporarily until the gas-preprocessor issues are worked
> out-- issues,
> >     >     >>>>> by the way, that were caused by Apple completely pulling
> the rug out
> >     >     >>>>> from underneath us vis-a-vis the compiler and
> assembler-- is not too
> >     >     >>>>> much to ask, in my opinion. Apple just unfortunately
> doesn't pay any
> >     >     >>>>> heed to backward compatibility. They want us to always
> use the latest &
> >     >     >>>>> greatest O/S, so they try to enforce that by making it
> more and more
> >     >     >>>>> difficult for developers to support older releases. It
> forces open
> >     >     >>>>> source developers, in particular, to be way more
> creative with build
> >     >     >>>>> tools than we'd prefer to be.
> >     >     >>>>>
> >     >     >>>>> I would like to support Xcode 5.0. In order to make that
> happen, then
> >     >     >>>>>gas-preprocessor.pl <http://gas-preprocessor.pl>
> >     <http://gas-preprocessor.pl>
> >     >     <http://gas-preprocessor.pl>
> >     >     >>>>> <http://gas-preprocessor.pl> needs to be modified
> >     >     >>>>> to work around a couple of
> >     >     >>>>> issues with LLVM/clang. The "invalid operand" issue is
> one of them.
> >     >     >>>>> The other is that, when you pass "-x assembler" to
> clang, which is
> >     >     >>>>> necessary when feeding it an assembly file via stdin like
> >     >     >>>>> gas-preprocessor does, it seems to ignore some of the
> other arguments.
> >     >     >>>>> The latter can be worked around in gas-preprocessor
> pretty easily, but
> >     >     >>>>> the former seems to be a basic incompatibility between
> the assembly
> >     >     >>>>> file
> >     >     >>>>> and the new assembler. The lines of code in question are
> unmodified
> >     >     >>>>> relative to the original assembly file, so the presence
> of
> >     >     >>>>> gas-preprocessor doesn't seem to be what's causing the
> failure. The
> >     >     >>>>> assembly code just won't assemble in clang. That is not
> something I am
> >     >     >>>>> capable of resolving, and note that I did spend about 4
> hours trying
> >     >     >>>>> various things in gas-preprocessor.
> >     >     >>>>>
> >     >     >>>>>
> >     >     >>>>> On 1/28/14 7:24 PM, Pol-Online wrote:
> >     >     >>>>>> For me it's mostly that Xcode 4.x is "deprecated" since
> 5.0 is
> >     >     >>>>>> out. I am
> >     >     >>>>>> fully aware some precompiled versions are available
> compatible with
> >     >     >>>>>> Xcode 5, which I am using in the mean time, but I like
> to build
> >     >     >>>>>> libraries myself, sometimes for "educational" purposes,
> sometimes
> >     >     >>>>>> for customization, which I can do with many libraries
> under Xcode5,
> >     >     >>>>>> except for libjpeg-turbo.
> >     >     >>>>>>
> >     >     >>>>>> -Pol
> >     >     >>>>>>
> >     >     >>>>>> ________________________________
> >     >     >>>>>> Pol-Online
> >     >     >>>>>>in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>
> >     >     >>>>>> <mailto:in...@po... <mailto:in...@po...
> >
> >     <mailto:in...@po... <mailto:in...@po...>>>
> >     >     >>>>>>
> >     >     >>>>>> On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
> >     >     >>>>>>
> >     >     >>>>>>> Is there any reason why you guys have to use Xcode
> 5.0? I mean,
> >     >     >>>>>>> we know
> >     >     >>>>>>> that the build works fine with Xcode 4.5.x and 4.6.x.
> It's quite easy
> >     >     >>>>>>> to install multiple versions of Xcode on the same
> system. Just name
> >     >     >>>>>>> Xcode 4.6 (for instance) /Applications/Xcode46.app and
> run (as root)
> >     >     >>>>>>> 'xcode-select --switch /Applications/Xcode46.app' to
> use it from the
> >     >     >>>>>>> command line.
> >     >     >>>>>>>
> >     >     >>>>>>> The static libraries we ship in the official
> libjpeg-turbo OS X
> >     >     >>>>>>> package
> >     >     >>>>>>> also contain ARM v6, v7, and v7s architectures, so you
> should be
> >     >     >>>>>>> able to
> >     >     >>>>>>> link directly with those rather than building
> libjpeg-turbo yourself.
> >     >     >>>>>>>
> >     >     >>>>>>> I treat libjpeg-turbo both as a project and a product.
> As much as
> >     >     >>>>>>> possible, I want it to be buildable by everyone, but I
> also don't
> >     >     >>>>>>> want
> >     >     >>>>>>> people to have to build it if they don't want to.
> >     >     >>>>>>>
> >     >     >>>>>>>
> >     >     >>>>>>> On 1/28/14 3:28 PM, George King wrote:
> >     >     >>>>>>>> I never got this to work either; please do let us
> know if you
> >     >     >>>>>>>> have any
> >     >     >>>>>>>> success!
> >     >     >>>
> >     >     >>>
> ------------------------------------------------------------------------------
> >     >     >>> WatchGuard Dimension instantly turns raw network data into
> actionable
> >     >     >>> security intelligence. It gives you real-time visual
> feedback on key
> >     >     >>> security issues and trends. Skip the complicated setup -
> simply import
> >     >     >>> a virtual appliance and go from zero to informed in
> seconds.
> >     >     >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> >     >     >>> _______________________________________________
> >     >     >>> Libjpeg-turbo-users mailing list
> >     >     >>>Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>
> >     >     >>> <mailto:Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>>
> >     >     >>>
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >     >>
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> ------------------------------------------------------------------------------
> >     >     > WatchGuard Dimension instantly turns raw network data into
> actionable
> >     >     > security intelligence. It gives you real-time visual
> feedback on key
> >     >     > security issues and trends.  Skip the complicated setup -
> simply import
> >     >     > a virtual appliance and go from zero to informed in seconds.
> >     >     >
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> >     >     >
> >     >     >
> >     >     >
> >     >     > _______________________________________________
> >     >     > Libjpeg-turbo-users mailing list
> >     >     >Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>
> >     >     >
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >     >
> >     >
> >     >
> ------------------------------------------------------------------------------
> >     >     WatchGuard Dimension instantly turns raw network data into
> actionable
> >     >     security intelligence. It gives you real-time visual feedback
> on key
> >     >     security issues and trends.  Skip the complicated setup -
> simply import
> >     >     a virtual appliance and go from zero to informed in seconds.
> >     >
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> >     >     _______________________________________________
> >     >     Libjpeg-turbo-users mailing list
> >     >Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>
> >     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >
> >     >
> >     >
> >     >
> >     >
> ------------------------------------------------------------------------------
> >     > Learn Graph Databases - Download FREE O'Reilly Book
> >     > "Graph Databases" is the definitive new guide to graph databases
> and their
> >     > applications. Written by three acclaimed leaders in the field,
> >     > this first edition is now available. Download your free book today!
> >     >http://p.sf.net/sfu/13534_NeoTech
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > Libjpeg-turbo-users mailing list
> >     >Lib...@li...
> >     <mailto:Lib...@li...>
> >     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >
> >
> >
> ------------------------------------------------------------------------------
> >     _______________________________________________
> >     Libjpeg-turbo-users mailing list
> >     Lib...@li...
> >     <mailto:Lib...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > Libjpeg-turbo-users mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

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

In reading further on it, basically the difference involves dynamic 
linking (which matches with my observation.)  If you're building an OS X 
app, for instance, and you want it to run on Snow Leopard, then you have 
two choices:

(A) build against the 10.6 SDK and specify -mmacosx-version-min=10.6
(B) build against a later SDK and specify -mmacosx-version-min=10.6

The second option will allow you to take advantage of features in the 
later version of the O/S.  Those will be weakly linked, so if the app is 
run on 10.6, the app won't fail unless it tries to access one of the new 
O/S features.  Option A limits the app to only using features of the 
older O/S.  I'm not sure whether dynamic linking is even a thing with 
iOS, but if it is, then I assume it would work similarly to the above. 
In the case of libjpeg-turbo, though, we're only using libSystem and 
libgcc, so there shouldn't be an appreciable difference between Options 
A and B.


On 3/27/14 10:22 AM, George King wrote:
> Thanks, your efforts are much appreciated. Moving the -no-integrated-as
> to CCASFLAGS worked. Regarding -miphoneos-version-min, I am only
> targeting 7.0 so I can't verify but it sounds reasonable.
>
>
>
> On Thu, Mar 27, 2014 at 12:00 AM, DRC <dco...@us...
> <mailto:dco...@us...>> wrote:
>
>     The latest version of BUILDING.txt in trunk and branches/1.3.x
>     (http://svn.code.sf.net/p/libjpeg-turbo/code/trunk/BUILDING.txt) has an
>     updated procedure that should now work with Xcode 5.1.
>
>     Basically, I had to move -no-integrated-as into CCASFLAGS so that it
>     only applies to the assembler code.  I also streamlined the instructions
>     somewhat.
>
>     Another note:  I guess I didn't realize that the iOS compilers have a
>     backward compatibility mechanism (-miphoneos-version-min) that is
>     similar to the one used by the OS X compilers (-mmacosx-version-min).  I
>     have traditionally not trusted any particular version of the OS X SDK to
>     produce proper binaries for an older version.  For instance, if you try
>     to use the Mountain Lion SDK with -mmacosx-version-min=10.5, you'll
>     technically get a Leopard-compatible binary, but the shared library
>     dependencies will be off.  Given that libjpeg-turbo doesn't have any
>     significant external dependencies, though, it should be possible to use
>     -miphoneos-version-min to build a backward-compatible version of it for
>     iOS (all the way back to 4.3) using the latest Xcode.  I'm curious to
>     hear from others as to how well this actually works.
>
>
>     On 3/26/14 5:10 PM, George King wrote:
>     > I agree that this is frustrating. I have one other comment, although I
>     > imagine this is far too much work to be immediately practical: libpng
>     > went through a similar ordeal, and I never got the gas-preprocessor
>     > approach working (although i think the final problem was related to
>     > symbol prefixes). Instead, somebody contributed a patch that used the
>     > arm neon intrinsics and all the ASM problems fell by the wayside. I'm
>     > not qualified to judge this in the context of jpeg-turbo, much less
>     > contribute such a patch, but it did provide an escape from the low-level
>     > tooling problems.
>     >
>     >
>     >
>     > On Wed, Mar 26, 2014 at 4:49 PM, DRC <dco...@us...
>     <mailto:dco...@us...>
>     > <mailto:dco...@us...
>     <mailto:dco...@us...>>> wrote:
>     >
>     >     <sigh>  You know, I used to complain about Microsoft, but despite the
>     >     fact that Microsoft software is like French cars-- in that they copy
>     >     nobody and nobody copies them-- at least MS provides really good
>     >     backward compatibility with themselves.  I mean, I can still use the
>     >     latest version of Visual C++ to produce a binary that runs on a
>     >     20-year-old obsolete operating system (Window NT 3.x.)
>     >
>     >     I guess I have no choice but to fix this again, even though I already
>     >     spent a lot of my time fixing it for XCode 5.0.  Really wishing Apple
>     >     would just stop changing things for the sake of changing things.  If
>     >     they were actually making things better, I wouldn't object, but here we
>     >     sit still getting 20% worse performance out of their new compilers than
>     >     their old compilers, and they are aware of it, and they just don't seem
>     >     to care.  I wonder sometimes if they actually use their own development
>     >     tools.  They certainly don't use them to build open source code, that's
>     >     for sure.
>     >
>     >
>     >     On 3/26/14 2:26 PM, George King wrote:
>     >     > First off, I want to extend a big thank you for the compatibility work
>     >     > that DRC and everyone else has done to make this compile with clang.
>     >     > While I recognize that there are performance issues with clang, the
>     >     > ability to build libjpeg with the same toolchain that I use for all of
>     >     > my other work is valuable, and I hope that we can maintain this
>     >     > compatibility.
>     >     >
>     >     > Unfortunately, my build script broke after upgrading to Xcode 5.1. It
>     >     > appears to be caused by the '-no-integrated-asm' flag, although I am not
>     >     > familiar with the exact mechanism (I say this because I was passing that
>     >     > flag to build scripts for several other libraries, sqlite3 and libpng
>     >     > among others, and they both showed similar errors).
>     >     >
>     >     > I would like to help debug this more, but I'm stumped by the fact that
>     >     > the .s file referenced in the error is a temporary, and seems to be
>     >     > removed by the time make exits. I think this is due to
>     >     >gas-preprocessor.pl <http://gas-preprocessor.pl>
>     <http://gas-preprocessor.pl>
>     >     <http://gas-preprocessor.pl>, right?
>     >     >
>     >     > Removing the -no-integrated-asm flag causes the older errors we saw in
>     >     > jsimd_arm_neon.S; if I also add the --without-simd configuration flag
>     >     > then the build succeeds.
>     >     >
>     >     > I tried on both libjpeg-turbo 1.3.0 and 1.3.1. I am using the latest
>     >     >gas-preprocessor.pl <http://gas-preprocessor.pl>
>     <http://gas-preprocessor.pl>
>     >     <http://gas-preprocessor.pl> from
>     >     >https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor;
>     >     > it has not changed since I had this working. Note also that Xcode 5.1
>     >     > contains only the ios7.1 sdk, so that version number will need to be
>     >     > bumped in any build setups.
>     >     >
>     >     > Thanks in advance,
>     >     > George
>     >     >
>     >     > + /Users/gwk/external/libjpeg-turbo-1.3.0/configure
>     >     > --disable-dependency-tracking
>     >     > --prefix=/Users/gwk/work/libqk/_tmp_build/ios-turbojpeg/armv7/install
>     >     > --host=arm-apple-darwin10 --enable-static --disable-shared
>     >     > --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
>     >     > LIBTOOL=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool
>     >     > CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>     >     > CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
>     >     > LD=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
>     >     > 'CFLAGS=-O3 -no-integrated-as ' 'CPPFLAGS=-arch armv7
>     >     > -miphoneos-version-min=7.0 -isysroot
>     >     > /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
>     >     > -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include'
>     >     > 'LDFLAGS= -arch armv7 -miphoneos-version-min=7.0 -isysroot
>     >     > /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
>     >     > -L/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/lib'
>     >     > --with-jpeg8 --without-simd
>     >     >
>     >     >
>     >     > libtool: compile:
>     >     >   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7 -miphoneos-version-min=7.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcparam.c -o jcparam.o
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:227:']'
>     >     > expected -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:228:']'
>     >     > expected -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:667:']'
>     >     > expected -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:668:']'
>     >     > expected -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:1093:']'
>     >     > expected -- `vld1.64 {d16,d17},[r3:128]'
>     >     > /bin/sh ./libtool  --tag=CC   --mode=compile
>     >     > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>     >     > -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0   -arch
>     >     > armv7 -miphoneos-version-min=7.0 -isysroot
>     >     > /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
>     >     > -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
>     >     >   -O3 -no-integrated-as  -c -o jcphuff.lo
>     >     > /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c
>     >     > clang: error: assembler command failed with exit code 1 (use -v to see
>     >     > invocation)
>     >     > make[2]: *** [jcdctmgr.lo] Error 1
>     >     > make[2]: *** Waiting for unfinished jobs....
>     >     > libtool: compile:
>     >     >   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7 -miphoneos-version-min=7.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c -o jcphuff.o
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:386:']' expected
>     >     > -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:387:']' expected
>     >     > -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:397:']' expected
>     >     > -- `vld1.64 {d18,d19},[r2:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:400:']' expected
>     >     > -- `vld1.64 {d20,d21},[r2:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:402:']' expected
>     >     > -- `vld1.64 {d24,d25},[r2:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:404:']' expected
>     >     > -- `vld1.64 {d22,d23},[r2:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:406:']' expected
>     >     > -- `vld1.64 {d26,d27},[r2:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:408:']' expected
>     >     > -- `vld1.64 {d28,d29},[r2:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:410:']' expected
>     >     > -- `vld1.64 {d30,d31},[r2:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:412:']' expected
>     >     > -- `vld1.64 {d16,d17},[r2:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:414:']' expected
>     >     > -- `vst1.64 {d16,d17},[lr:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:415:']' expected
>     >     > -- `vld1.64 {d16,d17},[r2:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:417:']' expected
>     >     > -- `vst1.64 {d16,d17},[sp:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:429:']' expected
>     >     > -- `vld1.64 {d16,d17},[r5:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:449:']' expected
>     >     > -- `vld1.64 {d16,d17},[sp:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:466:']' expected
>     >     > -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:467:']' expected
>     >     > -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
>     >     > clang: error: assembler command failed with exit code 1 (use -v to see
>     >     > invocation)
>     >     > make[2]: *** [jccolor.lo] Error 1
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1310:']'
>     >     > expected -- `vld1.64 {d16,d17},[r1:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1441:']'
>     >     > expected -- `vld1.64 {d16,d17},[r3:128]'
>     >     > clang: error: assembler command failed with exit code 1 (use -v to see
>     >     > invocation)
>     >     > make[2]: *** [jcparam.lo] Error 1
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1044:']'
>     >     > expected -- `vst1.64 {d8,d9},[r4:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1088:']'
>     >     > expected -- `vld1.32 {d16[0]},[r3:32]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1093:']'
>     >     > expected -- `vld1.32 {d18[0]},[r1:32]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1768:']'
>     >     > expected -- `vld1.64 {d8,d9},[r4:128]'
>     >     > /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1786:']'
>     >     > expected -- `vld1.64 {d8,d9},[r4:128]'
>     >     > clang: error: assembler command failed with exit code 1 (use -v to see
>     >     > invocation)
>     >     > make[2]: *** [jcmarker.lo] Error 1
>     >     > make[1]: *** [all-recursive] Error 1
>     >     > make: *** [all] Error 2
>     >     >
>     >     >
>     >     >
>     >     > On Wed, Jan 29, 2014 at 5:18 PM, DRC <dco...@us...
>     <mailto:dco...@us...>
>     >     <mailto:dco...@us...
>     <mailto:dco...@us...>>
>     >     > <mailto:dco...@us...
>     <mailto:dco...@us...>
>     >     <mailto:dco...@us...
>     <mailto:dco...@us...>>>> wrote:
>     >     >
>     >     >     I need to add one other thing, which is another reason why I recommended
>     >     >     either building these libraries with GCC or using our pre-built
>     >     >     binaries.  There is a known issue whereby libjpeg-turbo performs
>     >     >     significantly worse when built with Clang vs. GCC.  Basically, pure GCC
>     >     >     performs best, LLVM with the GCC front end performs less well, and LLVM
>     >     >     with the Clang front end performs worst.  The difference is as much as
>     >     >     20%.  Apple and the LLVM developers are aware of this, but nothing has
>     >     >     happened on their end yet:
>     >     >
>     >     >http://llvm.org/bugs/show_bug.cgi?id=16035
>     >     >
>     >     >     The official OS X/iOS binaries for libjpeg-turbo contain the following
>     >     >     architectures:
>     >     >
>     >     >     i386, OS X 10.4+
>     >     >     x86-64, OS X 10.4+
>     >     >     32-bit armv6, iOS 4.3+
>     >     >     32-bit armv7, iOS 4.3+
>     >     >     32-bit armv7s, iOS 6.0+
>     >     >
>     >     >     There is no option to use pure GCC with ARM code, but I use LLVM/GCC in
>     >     >     all of the ARM cases, so the binaries are as fast as possible.
>     >     >
>     >     >     Once we have a complete 64-bit ARM implementation, I intend to add a
>     >     >     64-bit armv8 architecture to the official binaries as well.
>     >     >
>     >     >     It takes significant effort to create these multi-architecture binaries.
>     >     >        That effort is done on our end so you don't have to do it on your
>     >     >     end.
>     >     >        My scripts for creating these binaries are fully open as well and can
>     >     >     be found here:
>     >     >https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/buildscripts/libjpeg-turbo/
>     >     >
>     >     >     The official binaries I provide should be usable by any OS X or iOS app
>     >     >     on any current OS X/iOS platform.  If they aren't, then I consider that
>     >     >     to be a bug, and I'd like to hear about it.  Although I certainly want
>     >     >     to enable people to build their own binaries, the official ones are the
>     >     >     only ones that I support or recommend, because some of the performance
>     >     >     and usability aspects of these binaries are a product of how they
>     >     >     are built.
>     >     >
>     >     >
>     >     >     On 1/29/14 3:59 PM, Pol-Online wrote:
>     >     >     > I’ve done more testing and things appear to be working fine. For those
>     >     >     > of you who are interested, build script and pre-built libraries with
>     >     >     > Xcode5 / Clang are available here:https://github.com/swisspol/Libraries
>     >     >     >
>     >     >     > Thanks again!
>     >     >     >
>     >     >     > -Pol
>     >     >     >
>     >     >     > ________________________________
>     >     >     > Pol-Online
>     >     >     >in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>
>     >     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>>
>     >     >     >
>     >     >     > On Wednesday, January 29, 2014 at 1:38 PM, Pol-Online wrote:
>     >     >     >
>     >     >     >> Most impressive, thanks! I can confirm it builds fine for armv7 and
>     >     >     >> the autoreconf hack is not needed anymore but I will do more tests. In
>     >     >     >> the meantime, here’s my updated fully self contained test build script:
>     >     >     >>https://gist.github.com/swisspol/8498104
>     >     >     >>
>     >     >     >> -Pol
>     >     >     >>
>     >     >     >> ________________________________
>     >     >     >> Pol-Online
>     >     >     >>in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>
>     >     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>>
>     >     >     >>
>     >     >     >> On Wednesday, January 29, 2014 at 1:26 PM, DRC wrote:
>     >     >     >>
>     >     >     >>> I think I finally fixed this. Two things are now required. First, use
>     >     >     >>> my modifiedversionofgas-preprocessor.pl <http://versionofgas-preprocessor.pl>
>     <http://ofgas-preprocessor.pl>
>     >     <http://gas-preprocessor.pl>
>     >     >     <http://gas-preprocessor.pl>:
>     >     >     >>>
>     >     >     >>>https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/
>     >     >     >>>
>     >     >     >>> This works around the Clang issue (bug) whereby it would ignore all
>     >     >     >>> other arguments if -x assembler is specified. Now,
>     >     >     >>>gas-preprocessor.pl <http://gas-preprocessor.pl>
>     <http://gas-preprocessor.pl>
>     >     <http://gas-preprocessor.pl>
>     >     >     <http://gas-preprocessor.pl>
>     >     >     >>> just creates a temporary file and executes the assembler with that
>     >     >     >>> temporary file, rather than trying to pipe its output into the assembler
>     >     >     >>> via stdin. This eliminates the need to specify -x assembler, which
>     >     >     >>> works around the Clang bug.
>     >     >     >>>
>     >     >     >>> Next, you need to add -no-integrated-as to your CFLAGS.
>     >     >     >>>
>     >     >     >>> I have updated BUILDING.txt with the new instructions for Xcode 5.0.
>     >     >     >>> Please let me know if you run into any problems.
>     >     >     >>>
>     >     >     >>>
>     >     >     >>> On 1/29/14 10:29 AM, Pol-Online wrote:
>     >     >     >>>> Thanks for your help and efforts! I updated the issue I opened in GitHub
>     >     >     >>>> against gas-preprocessor with your comments:
>     >     >     >>>>https://github.com/yuvi/gas-preprocessor/issues/26
>     >     >     >>>>
>     >     >     >>>> -Pol
>     >     >     >>>>
>     >     >     >>>> ________________________________
>     >     >     >>>> Pol-Online
>     >     >     >>>>in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>
>     >     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>>
>     >     >     >>>> <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>>
>     >     >     >>>>
>     >     >     >>>> On Wednesday, January 29, 2014 at 12:56 AM, DRC wrote:
>     >     >     >>>>
>     >     >     >>>>> If you want to build an iOS binary of libjpeg-turbo from source for
>     >     >     >>>>> educational or tinkering purposes, then for the moment, you're going to
>     >     >     >>>>> have to use a "deprecated" version of Xcode. I mean, I still use Xcode
>     >     >     >>>>> 3.2.6 to produce the official binaries for this project, because that's
>     >     >     >>>>> the only way I can support OS X 10.5. Asking others to use Xcode 4.6.x
>     >     >     >>>>> temporarily until the gas-preprocessor issues are worked out-- issues,
>     >     >     >>>>> by the way, that were caused by Apple completely pulling the rug out
>     >     >     >>>>> from underneath us vis-a-vis the compiler and assembler-- is not too
>     >     >     >>>>> much to ask, in my opinion. Apple just unfortunately doesn't pay any
>     >     >     >>>>> heed to backward compatibility. They want us to always use the latest &
>     >     >     >>>>> greatest O/S, so they try to enforce that by making it more and more
>     >     >     >>>>> difficult for developers to support older releases. It forces open
>     >     >     >>>>> source developers, in particular, to be way more creative with build
>     >     >     >>>>> tools than we'd prefer to be.
>     >     >     >>>>>
>     >     >     >>>>> I would like to support Xcode 5.0. In order to make that happen, then
>     >     >     >>>>>gas-preprocessor.pl <http://gas-preprocessor.pl>
>     <http://gas-preprocessor.pl>
>     >     <http://gas-preprocessor.pl>
>     >     >     <http://gas-preprocessor.pl>
>     >     >     >>>>> <http://gas-preprocessor.pl> needs to be modified
>     >     >     >>>>> to work around a couple of
>     >     >     >>>>> issues with LLVM/clang. The "invalid operand" issue is one of them.
>     >     >     >>>>> The other is that, when you pass "-x assembler" to clang, which is
>     >     >     >>>>> necessary when feeding it an assembly file via stdin like
>     >     >     >>>>> gas-preprocessor does, it seems to ignore some of the other arguments.
>     >     >     >>>>> The latter can be worked around in gas-preprocessor pretty easily, but
>     >     >     >>>>> the former seems to be a basic incompatibility between the assembly
>     >     >     >>>>> file
>     >     >     >>>>> and the new assembler. The lines of code in question are unmodified
>     >     >     >>>>> relative to the original assembly file, so the presence of
>     >     >     >>>>> gas-preprocessor doesn't seem to be what's causing the failure. The
>     >     >     >>>>> assembly code just won't assemble in clang. That is not something I am
>     >     >     >>>>> capable of resolving, and note that I did spend about 4 hours trying
>     >     >     >>>>> various things in gas-preprocessor.
>     >     >     >>>>>
>     >     >     >>>>>
>     >     >     >>>>> On 1/28/14 7:24 PM, Pol-Online wrote:
>     >     >     >>>>>> For me it’s mostly that Xcode 4.x is “deprecated” since 5.0 is
>     >     >     >>>>>> out. I am
>     >     >     >>>>>> fully aware some precompiled versions are available compatible with
>     >     >     >>>>>> Xcode 5, which I am using in the mean time, but I like to build
>     >     >     >>>>>> libraries myself, sometimes for “educational” purposes, sometimes
>     >     >     >>>>>> for customization, which I can do with many libraries under Xcode5,
>     >     >     >>>>>> except for libjpeg-turbo.
>     >     >     >>>>>>
>     >     >     >>>>>> -Pol
>     >     >     >>>>>>
>     >     >     >>>>>> ________________________________
>     >     >     >>>>>> Pol-Online
>     >     >     >>>>>>in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>
>     >     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>>
>     >     >     >>>>>> <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>
>     >     <mailto:in...@po... <mailto:in...@po...>
>     <mailto:in...@po... <mailto:in...@po...>>>>
>     >     >     >>>>>>
>     >     >     >>>>>> On Tuesday, January 28, 2014 at 1:40 PM, DRC wrote:
>     >     >     >>>>>>
>     >     >     >>>>>>> Is there any reason why you guys have to use Xcode 5.0? I mean,
>     >     >     >>>>>>> we know
>     >     >     >>>>>>> that the build works fine with Xcode 4.5.x and 4.6.x. It's quite easy
>     >     >     >>>>>>> to install multiple versions of Xcode on the same system. Just name
>     >     >     >>>>>>> Xcode 4.6 (for instance) /Applications/Xcode46.app and run (as root)
>     >     >     >>>>>>> 'xcode-select --switch /Applications/Xcode46.app' to use it from the
>     >     >     >>>>>>> command line.
>     >     >     >>>>>>>
>     >     >     >>>>>>> The static libraries we ship in the official libjpeg-turbo OS X
>     >     >     >>>>>>> package
>     >     >     >>>>>>> also contain ARM v6, v7, and v7s architectures, so you should be
>     >     >     >>>>>>> able to
>     >     >     >>>>>>> link directly with those rather than building libjpeg-turbo yourself.
>     >     >     >>>>>>>
>     >     >     >>>>>>> I treat libjpeg-turbo both as a project and a product. As much as
>     >     >     >>>>>>> possible, I want it to be buildable by everyone, but I also don't
>     >     >     >>>>>>> want
>     >     >     >>>>>>> people to have to build it if they don't want to.
>     >     >     >>>>>>>
>     >     >     >>>>>>>
>     >     >     >>>>>>> On 1/28/14 3:28 PM, George King wrote:
>     >     >     >>>>>>>> I never got this to work either; please do let us know if you
>     >     >     >>>>>>>> have any
>     >     >     >>>>>>>> success!
>     >     >     >>>
>     >     >     >>> ------------------------------------------------------------------------------
>     >     >     >>> WatchGuard Dimension instantly turns raw network data into actionable
>     >     >     >>> security intelligence. It gives you real-time visual feedback on key
>     >     >     >>> security issues and trends. Skip the complicated setup - simply import
>     >     >     >>> a virtual appliance and go from zero to informed in seconds.
>     >     >     >>>http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>     >     >     >>> _______________________________________________
>     >     >     >>> Libjpeg-turbo-users mailing list
>     >     >     >>>Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>
>     >     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>>
>     >     >     >>> <mailto:Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>
>     >     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>>>
>     >     >     >>>https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >     >     >>
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     > ------------------------------------------------------------------------------
>     >     >     > WatchGuard Dimension instantly turns raw network data into actionable
>     >     >     > security intelligence. It gives you real-time visual feedback on key
>     >     >     > security issues and trends.  Skip the complicated setup - simply import
>     >     >     > a virtual appliance and go from zero to informed in seconds.
>     >     >     >http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     > _______________________________________________
>     >     >     > Libjpeg-turbo-users mailing list
>     >     >     >Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>
>     >     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>>
>     >     >     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >     >     >
>     >     >
>     >     >     ------------------------------------------------------------------------------
>     >     >     WatchGuard Dimension instantly turns raw network data into actionable
>     >     >     security intelligence. It gives you real-time visual feedback on key
>     >     >     security issues and trends.  Skip the complicated setup - simply import
>     >     >     a virtual appliance and go from zero to informed in seconds.
>     >     >http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>     >     >     _______________________________________________
>     >     >     Libjpeg-turbo-users mailing list
>     >     >Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>
>     >     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>>
>     >     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > ------------------------------------------------------------------------------
>     >     > Learn Graph Databases - Download FREE O'Reilly Book
>     >     > "Graph Databases" is the definitive new guide to graph databases and their
>     >     > applications. Written by three acclaimed leaders in the field,
>     >     > this first edition is now available. Download your free book today!
>     >     >http://p.sf.net/sfu/13534_NeoTech
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > Libjpeg-turbo-users mailing list
>     >     >Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>
>     >     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >     >
>     >
>     >     ------------------------------------------------------------------------------
>     >     _______________________________________________
>     >     Libjpeg-turbo-users mailing list
>     >Lib...@li...
>     <mailto:Lib...@li...>
>     >     <mailto:Lib...@li...
>     <mailto:Lib...@li...>>
>     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >
>     >
>     >
>     >
>     > ------------------------------------------------------------------------------
>     >
>     >
>     >
>     > _______________________________________________
>     > Libjpeg-turbo-users mailing list
>     >Lib...@li...
>     <mailto:Lib...@li...>
>     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>     >
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Libjpeg-turbo-users mailing list
>     Lib...@li...
>     <mailto:Lib...@li...>
>     https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[George K. <gwk...@gm...>]

3rd party dylibs are forbidden on iOS as part of their app store policy, so
I don't think it matters.


On Thu, Mar 27, 2014 at 12:16 PM, DRC <dco...@us...>wrote:

> In reading further on it, basically the difference involves dynamic
> linking (which matches with my observation.)  If you're building an OS X
> app, for instance, and you want it to run on Snow Leopard, then you have
> two choices:
>
> (A) build against the 10.6 SDK and specify -mmacosx-version-min=10.6
> (B) build against a later SDK and specify -mmacosx-version-min=10.6
>
> The second option will allow you to take advantage of features in the
> later version of the O/S.  Those will be weakly linked, so if the app is
> run on 10.6, the app won't fail unless it tries to access one of the new
> O/S features.  Option A limits the app to only using features of the
> older O/S.  I'm not sure whether dynamic linking is even a thing with
> iOS, but if it is, then I assume it would work similarly to the above.
> In the case of libjpeg-turbo, though, we're only using libSystem and
> libgcc, so there shouldn't be an appreciable difference between Options
> A and B.
>
>
> On 3/27/14 10:22 AM, George King wrote:
> > Thanks, your efforts are much appreciated. Moving the -no-integrated-as
> > to CCASFLAGS worked. Regarding -miphoneos-version-min, I am only
> > targeting 7.0 so I can't verify but it sounds reasonable.
> >
> >
> >
> > On Thu, Mar 27, 2014 at 12:00 AM, DRC <dco...@us...
> > <mailto:dco...@us...>> wrote:
> >
> >     The latest version of BUILDING.txt in trunk and branches/1.3.x
> >     (http://svn.code.sf.net/p/libjpeg-turbo/code/trunk/BUILDING.txt)
> has an
> >     updated procedure that should now work with Xcode 5.1.
> >
> >     Basically, I had to move -no-integrated-as into CCASFLAGS so that it
> >     only applies to the assembler code.  I also streamlined the
> instructions
> >     somewhat.
> >
> >     Another note:  I guess I didn't realize that the iOS compilers have a
> >     backward compatibility mechanism (-miphoneos-version-min) that is
> >     similar to the one used by the OS X compilers
> (-mmacosx-version-min).  I
> >     have traditionally not trusted any particular version of the OS X
> SDK to
> >     produce proper binaries for an older version.  For instance, if you
> try
> >     to use the Mountain Lion SDK with -mmacosx-version-min=10.5, you'll
> >     technically get a Leopard-compatible binary, but the shared library
> >     dependencies will be off.  Given that libjpeg-turbo doesn't have any
> >     significant external dependencies, though, it should be possible to
> use
> >     -miphoneos-version-min to build a backward-compatible version of it
> for
> >     iOS (all the way back to 4.3) using the latest Xcode.  I'm curious to
> >     hear from others as to how well this actually works.
> >
> >
> >     On 3/26/14 5:10 PM, George King wrote:
> >     > I agree that this is frustrating. I have one other comment,
> although I
> >     > imagine this is far too much work to be immediately practical:
> libpng
> >     > went through a similar ordeal, and I never got the gas-preprocessor
> >     > approach working (although i think the final problem was related to
> >     > symbol prefixes). Instead, somebody contributed a patch that used
> the
> >     > arm neon intrinsics and all the ASM problems fell by the wayside.
> I'm
> >     > not qualified to judge this in the context of jpeg-turbo, much less
> >     > contribute such a patch, but it did provide an escape from the
> low-level
> >     > tooling problems.
> >     >
> >     >
> >     >
> >     > On Wed, Mar 26, 2014 at 4:49 PM, DRC <
> dco...@us...
> >     <mailto:dco...@us...>
> >     > <mailto:dco...@us...
> >     <mailto:dco...@us...>>> wrote:
> >     >
> >     >     <sigh>  You know, I used to complain about Microsoft, but
> despite the
> >     >     fact that Microsoft software is like French cars-- in that
> they copy
> >     >     nobody and nobody copies them-- at least MS provides really
> good
> >     >     backward compatibility with themselves.  I mean, I can still
> use the
> >     >     latest version of Visual C++ to produce a binary that runs on a
> >     >     20-year-old obsolete operating system (Window NT 3.x.)
> >     >
> >     >     I guess I have no choice but to fix this again, even though I
> already
> >     >     spent a lot of my time fixing it for XCode 5.0.  Really
> wishing Apple
> >     >     would just stop changing things for the sake of changing
> things.  If
> >     >     they were actually making things better, I wouldn't object,
> but here we
> >     >     sit still getting 20% worse performance out of their new
> compilers than
> >     >     their old compilers, and they are aware of it, and they just
> don't seem
> >     >     to care.  I wonder sometimes if they actually use their own
> development
> >     >     tools.  They certainly don't use them to build open source
> code, that's
> >     >     for sure.
> >     >
> >     >
> >     >     On 3/26/14 2:26 PM, George King wrote:
> >     >     > First off, I want to extend a big thank you for the
> compatibility work
> >     >     > that DRC and everyone else has done to make this compile
> with clang.
> >     >     > While I recognize that there are performance issues with
> clang, the
> >     >     > ability to build libjpeg with the same toolchain that I use
> for all of
> >     >     > my other work is valuable, and I hope that we can maintain
> this
> >     >     > compatibility.
> >     >     >
> >     >     > Unfortunately, my build script broke after upgrading to
> Xcode 5.1. It
> >     >     > appears to be caused by the '-no-integrated-asm' flag,
> although I am not
> >     >     > familiar with the exact mechanism (I say this because I was
> passing that
> >     >     > flag to build scripts for several other libraries, sqlite3
> and libpng
> >     >     > among others, and they both showed similar errors).
> >     >     >
> >     >     > I would like to help debug this more, but I'm stumped by the
> fact that
> >     >     > the .s file referenced in the error is a temporary, and
> seems to be
> >     >     > removed by the time make exits. I think this is due to
> >     >     >gas-preprocessor.pl <http://gas-preprocessor.pl>
> >     <http://gas-preprocessor.pl>
> >     >     <http://gas-preprocessor.pl>, right?
> >     >     >
> >     >     > Removing the -no-integrated-asm flag causes the older errors
> we saw in
> >     >     > jsimd_arm_neon.S; if I also add the --without-simd
> configuration flag
> >     >     > then the build succeeds.
> >     >     >
> >     >     > I tried on both libjpeg-turbo 1.3.0 and 1.3.1. I am using
> the latest
> >     >     >gas-preprocessor.pl <http://gas-preprocessor.pl>
> >     <http://gas-preprocessor.pl>
> >     >     <http://gas-preprocessor.pl> from
> >     >     >
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor;
> >     >     > it has not changed since I had this working. Note also that
> Xcode 5.1
> >     >     > contains only the ios7.1 sdk, so that version number will
> need to be
> >     >     > bumped in any build setups.
> >     >     >
> >     >     > Thanks in advance,
> >     >     > George
> >     >     >
> >     >     > + /Users/gwk/external/libjpeg-turbo-1.3.0/configure
> >     >     > --disable-dependency-tracking
> >     >     >
> --prefix=/Users/gwk/work/libqk/_tmp_build/ios-turbojpeg/armv7/install
> >     >     > --host=arm-apple-darwin10 --enable-static --disable-shared
> >     >     >
> --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >     >     >
> LIBTOOL=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool
> >     >     >
> CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> >     >     >
> CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
> >     >     >
> LD=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
> >     >     > 'CFLAGS=-O3 -no-integrated-as ' 'CPPFLAGS=-arch armv7
> >     >     > -miphoneos-version-min=7.0 -isysroot
> >     >     >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >     >     >
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include'
> >     >     > 'LDFLAGS= -arch armv7 -miphoneos-version-min=7.0 -isysroot
> >     >     >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >     >     >
> -L/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/lib'
> >     >     > --with-jpeg8 --without-simd
> >     >     >
> >     >     >
> >     >     > libtool: compile:
> >     >     >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7
> -miphoneos-version-min=7.0 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
> -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcparam.c
> -o jcparam.o
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:227:']'
> >     >     > expected -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:228:']'
> >     >     > expected -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:667:']'
> >     >     > expected -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:668:']'
> >     >     > expected -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcdctmgr-157433.s:1093:']'
> >     >     > expected -- `vld1.64 {d16,d17},[r3:128]'
> >     >     > /bin/sh ./libtool  --tag=CC   --mode=compile
> >     >     >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> >     >     > -DHAVE_CONFIG_H -I.
> -I/Users/gwk/external/libjpeg-turbo-1.3.0   -arch
> >     >     > armv7 -miphoneos-version-min=7.0 -isysroot
> >     >     >
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> >     >     >
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
> >     >     >   -O3 -no-integrated-as  -c -o jcphuff.lo
> >     >     > /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c
> >     >     > clang: error: assembler command failed with exit code 1 (use
> -v to see
> >     >     > invocation)
> >     >     > make[2]: *** [jcdctmgr.lo] Error 1
> >     >     > make[2]: *** Waiting for unfinished jobs....
> >     >     > libtool: compile:
> >     >     >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> -DHAVE_CONFIG_H -I. -I/Users/gwk/external/libjpeg-turbo-1.3.0 -arch armv7
> -miphoneos-version-min=7.0 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/include
> -O3 -no-integrated-as -c /Users/gwk/external/libjpeg-turbo-1.3.0/jcphuff.c
> -o jcphuff.o
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:386:']'
> expected
> >     >     > -- `vst1.64 {d8,d9,d10,d11},[r4:128]!'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:387:']'
> expected
> >     >     > -- `vst1.64 {d12,d13,d14,d15},[r4:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:397:']'
> expected
> >     >     > -- `vld1.64 {d18,d19},[r2:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:400:']'
> expected
> >     >     > -- `vld1.64 {d20,d21},[r2:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:402:']'
> expected
> >     >     > -- `vld1.64 {d24,d25},[r2:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:404:']'
> expected
> >     >     > -- `vld1.64 {d22,d23},[r2:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:406:']'
> expected
> >     >     > -- `vld1.64 {d26,d27},[r2:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:408:']'
> expected
> >     >     > -- `vld1.64 {d28,d29},[r2:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:410:']'
> expected
> >     >     > -- `vld1.64 {d30,d31},[r2:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:412:']'
> expected
> >     >     > -- `vld1.64 {d16,d17},[r2:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:414:']'
> expected
> >     >     > -- `vst1.64 {d16,d17},[lr:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:415:']'
> expected
> >     >     > -- `vld1.64 {d16,d17},[r2:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:417:']'
> expected
> >     >     > -- `vst1.64 {d16,d17},[sp:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:429:']'
> expected
> >     >     > -- `vld1.64 {d16,d17},[r5:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:449:']'
> expected
> >     >     > -- `vld1.64 {d16,d17},[sp:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:466:']'
> expected
> >     >     > -- `vld1.64 {d8,d9,d10,d11},[r4:128]!'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jccolor-42addf.s:467:']'
> expected
> >     >     > -- `vld1.64 {d12,d13,d14,d15},[r4:128]'
> >     >     > clang: error: assembler command failed with exit code 1 (use
> -v to see
> >     >     > invocation)
> >     >     > make[2]: *** [jccolor.lo] Error 1
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1310:']'
> >     >     > expected -- `vld1.64 {d16,d17},[r1:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcparam-42d1a0.s:1441:']'
> >     >     > expected -- `vld1.64 {d16,d17},[r3:128]'
> >     >     > clang: error: assembler command failed with exit code 1 (use
> -v to see
> >     >     > invocation)
> >     >     > make[2]: *** [jcparam.lo] Error 1
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1044:']'
> >     >     > expected -- `vst1.64 {d8,d9},[r4:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1088:']'
> >     >     > expected -- `vld1.32 {d16[0]},[r3:32]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1093:']'
> >     >     > expected -- `vld1.32 {d18[0]},[r1:32]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1768:']'
> >     >     > expected -- `vld1.64 {d8,d9},[r4:128]'
> >     >     >
> /var/folders/4x/8xpncq5x1qz0g34j_ykw9j340000gn/T/jcmarker-ff7507.s:1786:']'
> >     >     > expected -- `vld1.64 {d8,d9},[r4:128]'
> >     >     > clang: error: assembler command failed with exit code 1 (use
> -v to see
> >     >     > invocation)
> >     >     > make[2]: *** [jcmarker.lo] Error 1
> >     >     > make[1]: *** [all-recursive] Error 1
> >     >     > make: *** [all] Error 2
> >     >     >
> >     >     >
> >     >     >
> >     >     > On Wed, Jan 29, 2014 at 5:18 PM, DRC <
> dco...@us...
> >     <mailto:dco...@us...>
> >     >     <mailto:dco...@us...
> >     <mailto:dco...@us...>>
> >     >     > <mailto:dco...@us...
> >     <mailto:dco...@us...>
> >     >     <mailto:dco...@us...
> >     <mailto:dco...@us...>>>> wrote:
> >     >     >
> >     >     >     I need to add one other thing, which is another reason
> why I recommended
> >     >     >     either building these libraries with GCC or using our
> pre-built
> >     >     >     binaries.  There is a known issue whereby libjpeg-turbo
> performs
> >     >     >     significantly worse when built with Clang vs. GCC.
>  Basically, pure GCC
> >     >     >     performs best, LLVM with the GCC front end performs less
> well, and LLVM
> >     >     >     with the Clang front end performs worst.  The difference
> is as much as
> >     >     >     20%.  Apple and the LLVM developers are aware of this,
> but nothing has
> >     >     >     happened on their end yet:
> >     >     >
> >     >     >http://llvm.org/bugs/show_bug.cgi?id=16035
> >     >     >
> >     >     >     The official OS X/iOS binaries for libjpeg-turbo contain
> the following
> >     >     >     architectures:
> >     >     >
> >     >     >     i386, OS X 10.4+
> >     >     >     x86-64, OS X 10.4+
> >     >     >     32-bit armv6, iOS 4.3+
> >     >     >     32-bit armv7, iOS 4.3+
> >     >     >     32-bit armv7s, iOS 6.0+
> >     >     >
> >     >     >     There is no option to use pure GCC with ARM code, but I
> use LLVM/GCC in
> >     >     >     all of the ARM cases, so the binaries are as fast as
> possible.
> >     >     >
> >     >     >     Once we have a complete 64-bit ARM implementation, I
> intend to add a
> >     >     >     64-bit armv8 architecture to the official binaries as
> well.
> >     >     >
> >     >     >     It takes significant effort to create these
> multi-architecture binaries.
> >     >     >        That effort is done on our end so you don't have to
> do it on your
> >     >     >     end.
> >     >     >        My scripts for creating these binaries are fully open
> as well and can
> >     >     >     be found here:
> >     >     >
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/buildscripts/libjpeg-turbo/
> >     >     >
> >     >     >     The official binaries I provide should be usable by any
> OS X or iOS app
> >     >     >     on any current OS X/iOS platform.  If they aren't, then
> I consider that
> >     >     >     to be a bug, and I'd like to hear about it.  Although I
> certainly want
> >     >     >     to enable people to build their own binaries, the
> official ones are the
> >     >     >     only ones that I support or recommend, because some of
> the performance
> >     >     >     and usability aspects of these binaries are a product of
> how they
> >     >     >     are built.
> >     >     >
> >     >     >
> >     >     >     On 1/29/14 3:59 PM, Pol-Online wrote:
> >     >     >     > I've done more testing and things appear to be working
> fine. For those
> >     >     >     > of you who are interested, build script and pre-built
> libraries with
> >     >     >     > Xcode5 / Clang are available here:
> https://github.com/swisspol/Libraries
> >     >     >     >
> >     >     >     > Thanks again!
> >     >     >     >
> >     >     >     > -Pol
> >     >     >     >
> >     >     >     > ________________________________
> >     >     >     > Pol-Online
> >     >     >     >in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>
> >     >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>>
> >     >     >     >
> >     >     >     > On Wednesday, January 29, 2014 at 1:38 PM, Pol-Online
> wrote:
> >     >     >     >
> >     >     >     >> Most impressive, thanks! I can confirm it builds fine
> for armv7 and
> >     >     >     >> the autoreconf hack is not needed anymore but I will
> do more tests. In
> >     >     >     >> the meantime, here's my updated fully self contained
> test build script:
> >     >     >     >>https://gist.github.com/swisspol/8498104
> >     >     >     >>
> >     >     >     >> -Pol
> >     >     >     >>
> >     >     >     >> ________________________________
> >     >     >     >> Pol-Online
> >     >     >     >>in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>
> >     >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>>
> >     >     >     >>
> >     >     >     >> On Wednesday, January 29, 2014 at 1:26 PM, DRC wrote:
> >     >     >     >>
> >     >     >     >>> I think I finally fixed this. Two things are now
> required. First, use
> >     >     >     >>> my modifiedversionofgas-preprocessor.pl <
> http://versionofgas-preprocessor.pl>
> >     <http://ofgas-preprocessor.pl>
> >     >     <http://gas-preprocessor.pl>
> >     >     >     <http://gas-preprocessor.pl>:
> >     >     >     >>>
> >     >     >     >>>
> https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/gas-preprocessor/
> >     >     >     >>>
> >     >     >     >>> This works around the Clang issue (bug) whereby it
> would ignore all
> >     >     >     >>> other arguments if -x assembler is specified. Now,
> >     >     >     >>>gas-preprocessor.pl <http://gas-preprocessor.pl>
> >     <http://gas-preprocessor.pl>
> >     >     <http://gas-preprocessor.pl>
> >     >     >     <http://gas-preprocessor.pl>
> >     >     >     >>> just creates a temporary file and executes the
> assembler with that
> >     >     >     >>> temporary file, rather than trying to pipe its
> output into the assembler
> >     >     >     >>> via stdin. This eliminates the need to specify -x
> assembler, which
> >     >     >     >>> works around the Clang bug.
> >     >     >     >>>
> >     >     >     >>> Next, you need to add -no-integrated-as to your
> CFLAGS.
> >     >     >     >>>
> >     >     >     >>> I have updated BUILDING.txt with the new
> instructions for Xcode 5.0.
> >     >     >     >>> Please let me know if you run into any problems.
> >     >     >     >>>
> >     >     >     >>>
> >     >     >     >>> On 1/29/14 10:29 AM, Pol-Online wrote:
> >     >     >     >>>> Thanks for your help and efforts! I updated the
> issue I opened in GitHub
> >     >     >     >>>> against gas-preprocessor with your comments:
> >     >     >     >>>>https://github.com/yuvi/gas-preprocessor/issues/26
> >     >     >     >>>>
> >     >     >     >>>> -Pol
> >     >     >     >>>>
> >     >     >     >>>> ________________________________
> >     >     >     >>>> Pol-Online
> >     >     >     >>>>in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>
> >     >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>>
> >     >     >     >>>> <mailto:in...@po... <mailto:
> in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>>
> >     >     >     >>>>
> >     >     >     >>>> On Wednesday, January 29, 2014 at 12:56 AM, DRC
> wrote:
> >     >     >     >>>>
> >     >     >     >>>>> If you want to build an iOS binary of
> libjpeg-turbo from source for
> >     >     >     >>>>> educational or tinkering purposes, then for the
> moment, you're going to
> >     >     >     >>>>> have to use a "deprecated" version of Xcode. I
> mean, I still use Xcode
> >     >     >     >>>>> 3.2.6 to produce the official binaries for this
> project, because that's
> >     >     >     >>>>> the only way I can support OS X 10.5. Asking
> others to use Xcode 4.6.x
> >     >     >     >>>>> temporarily until the gas-preprocessor issues are
> worked out-- issues,
> >     >     >     >>>>> by the way, that were caused by Apple completely
> pulling the rug out
> >     >     >     >>>>> from underneath us vis-a-vis the compiler and
> assembler-- is not too
> >     >     >     >>>>> much to ask, in my opinion. Apple just
> unfortunately doesn't pay any
> >     >     >     >>>>> heed to backward compatibility. They want us to
> always use the latest &
> >     >     >     >>>>> greatest O/S, so they try to enforce that by
> making it more and more
> >     >     >     >>>>> difficult for developers to support older
> releases. It forces open
> >     >     >     >>>>> source developers, in particular, to be way more
> creative with build
> >     >     >     >>>>> tools than we'd prefer to be.
> >     >     >     >>>>>
> >     >     >     >>>>> I would like to support Xcode 5.0. In order to
> make that happen, then
> >     >     >     >>>>>gas-preprocessor.pl <http://gas-preprocessor.pl>
> >     <http://gas-preprocessor.pl>
> >     >     <http://gas-preprocessor.pl>
> >     >     >     <http://gas-preprocessor.pl>
> >     >     >     >>>>> <http://gas-preprocessor.pl> needs to be modified
> >     >     >     >>>>> to work around a couple of
> >     >     >     >>>>> issues with LLVM/clang. The "invalid operand"
> issue is one of them.
> >     >     >     >>>>> The other is that, when you pass "-x assembler" to
> clang, which is
> >     >     >     >>>>> necessary when feeding it an assembly file via
> stdin like
> >     >     >     >>>>> gas-preprocessor does, it seems to ignore some of
> the other arguments.
> >     >     >     >>>>> The latter can be worked around in
> gas-preprocessor pretty easily, but
> >     >     >     >>>>> the former seems to be a basic incompatibility
> between the assembly
> >     >     >     >>>>> file
> >     >     >     >>>>> and the new assembler. The lines of code in
> question are unmodified
> >     >     >     >>>>> relative to the original assembly file, so the
> presence of
> >     >     >     >>>>> gas-preprocessor doesn't seem to be what's causing
> the failure. The
> >     >     >     >>>>> assembly code just won't assemble in clang. That
> is not something I am
> >     >     >     >>>>> capable of resolving, and note that I did spend
> about 4 hours trying
> >     >     >     >>>>> various things in gas-preprocessor.
> >     >     >     >>>>>
> >     >     >     >>>>>
> >     >     >     >>>>> On 1/28/14 7:24 PM, Pol-Online wrote:
> >     >     >     >>>>>> For me it's mostly that Xcode 4.x is "deprecated"
> since 5.0 is
> >     >     >     >>>>>> out. I am
> >     >     >     >>>>>> fully aware some precompiled versions are
> available compatible with
> >     >     >     >>>>>> Xcode 5, which I am using in the mean time, but I
> like to build
> >     >     >     >>>>>> libraries myself, sometimes for "educational"
> purposes, sometimes
> >     >     >     >>>>>> for customization, which I can do with many
> libraries under Xcode5,
> >     >     >     >>>>>> except for libjpeg-turbo.
> >     >     >     >>>>>>
> >     >     >     >>>>>> -Pol
> >     >     >     >>>>>>
> >     >     >     >>>>>> ________________________________
> >     >     >     >>>>>> Pol-Online
> >     >     >     >>>>>>in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>
> >     >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>>
> >     >     >     >>>>>> <mailto:in...@po... <mailto:
> in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>
> >     >     <mailto:in...@po... <mailto:in...@po...>
> >     <mailto:in...@po... <mailto:in...@po...>>>>
> >     >     >     >>>>>>
> >     >     >     >>>>>> On Tuesday, January 28, 2014 at 1:40 PM, DRC
> wrote:
> >     >     >     >>>>>>
> >     >     >     >>>>>>> Is there any reason why you guys have to use
> Xcode 5.0? I mean,
> >     >     >     >>>>>>> we know
> >     >     >     >>>>>>> that the build works fine with Xcode 4.5.x and
> 4.6.x. It's quite easy
> >     >     >     >>>>>>> to install multiple versions of Xcode on the
> same system. Just name
> >     >     >     >>>>>>> Xcode 4.6 (for instance)
> /Applications/Xcode46.app and run (as root)
> >     >     >     >>>>>>> 'xcode-select --switch
> /Applications/Xcode46.app' to use it from the
> >     >     >     >>>>>>> command line.
> >     >     >     >>>>>>>
> >     >     >     >>>>>>> The static libraries we ship in the official
> libjpeg-turbo OS X
> >     >     >     >>>>>>> package
> >     >     >     >>>>>>> also contain ARM v6, v7, and v7s architectures,
> so you should be
> >     >     >     >>>>>>> able to
> >     >     >     >>>>>>> link directly with those rather than building
> libjpeg-turbo yourself.
> >     >     >     >>>>>>>
> >     >     >     >>>>>>> I treat libjpeg-turbo both as a project and a
> product. As much as
> >     >     >     >>>>>>> possible, I want it to be buildable by everyone,
> but I also don't
> >     >     >     >>>>>>> want
> >     >     >     >>>>>>> people to have to build it if they don't want to.
> >     >     >     >>>>>>>
> >     >     >     >>>>>>>
> >     >     >     >>>>>>> On 1/28/14 3:28 PM, George King wrote:
> >     >     >     >>>>>>>> I never got this to work either; please do let
> us know if you
> >     >     >     >>>>>>>> have any
> >     >     >     >>>>>>>> success!
> >     >     >     >>>
> >     >     >     >>>
> ------------------------------------------------------------------------------
> >     >     >     >>> WatchGuard Dimension instantly turns raw network
> data into actionable
> >     >     >     >>> security intelligence. It gives you real-time visual
> feedback on key
> >     >     >     >>> security issues and trends. Skip the complicated
> setup - simply import
> >     >     >     >>> a virtual appliance and go from zero to informed in
> seconds.
> >     >     >     >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> >     >     >     >>> _______________________________________________
> >     >     >     >>> Libjpeg-turbo-users mailing list
> >     >     >     >>>Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>
> >     >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>>
> >     >     >     >>> <mailto:Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>
> >     >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>>>
> >     >     >     >>>
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >     >     >>
> >     >     >     >
> >     >     >     >
> >     >     >     >
> >     >     >     >
> ------------------------------------------------------------------------------
> >     >     >     > WatchGuard Dimension instantly turns raw network data
> into actionable
> >     >     >     > security intelligence. It gives you real-time visual
> feedback on key
> >     >     >     > security issues and trends.  Skip the complicated
> setup - simply import
> >     >     >     > a virtual appliance and go from zero to informed in
> seconds.
> >     >     >     >
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> >     >     >     >
> >     >     >     >
> >     >     >     >
> >     >     >     > _______________________________________________
> >     >     >     > Libjpeg-turbo-users mailing list
> >     >     >     >Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>
> >     >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>>
> >     >     >     >
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >     >     >
> >     >     >
> >     >     >
> ------------------------------------------------------------------------------
> >     >     >     WatchGuard Dimension instantly turns raw network data
> into actionable
> >     >     >     security intelligence. It gives you real-time visual
> feedback on key
> >     >     >     security issues and trends.  Skip the complicated setup
> - simply import
> >     >     >     a virtual appliance and go from zero to informed in
> seconds.
> >     >     >
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> >     >     >     _______________________________________________
> >     >     >     Libjpeg-turbo-users mailing list
> >     >     >Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>
> >     >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>>
> >     >     >
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> ------------------------------------------------------------------------------
> >     >     > Learn Graph Databases - Download FREE O'Reilly Book
> >     >     > "Graph Databases" is the definitive new guide to graph
> databases and their
> >     >     > applications. Written by three acclaimed leaders in the
> field,
> >     >     > this first edition is now available. Download your free book
> today!
> >     >     >http://p.sf.net/sfu/13534_NeoTech
> >     >     >
> >     >     >
> >     >     >
> >     >     > _______________________________________________
> >     >     > Libjpeg-turbo-users mailing list
> >     >     >Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>
> >     >     >
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >     >
> >     >
> >     >
> ------------------------------------------------------------------------------
> >     >     _______________________________________________
> >     >     Libjpeg-turbo-users mailing list
> >     >Lib...@li...
> >     <mailto:Lib...@li...>
> >     >     <mailto:Lib...@li...
> >     <mailto:Lib...@li...>>
> >     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >
> >     >
> >     >
> >     >
> >     >
> ------------------------------------------------------------------------------
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > Libjpeg-turbo-users mailing list
> >     >Lib...@li...
> >     <mailto:Lib...@li...>
> >     >https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >     >
> >
> >
> ------------------------------------------------------------------------------
> >     _______________________________________________
> >     Libjpeg-turbo-users mailing list
> >     Lib...@li...
> >     <mailto:Lib...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > Libjpeg-turbo-users mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[Siarhei S. <sia...@gm...>]

On Wed, 26 Mar 2014 18:10:18 -0400
George King <gwk...@gm...> wrote:

> I agree that this is frustrating. I have one other comment, although I
> imagine this is far too much work to be immediately practical: libpng went
> through a similar ordeal, and I never got the gas-preprocessor approach
> working (although i think the final problem was related to symbol
> prefixes). Instead, somebody contributed a patch that used the arm neon
> intrinsics and all the ASM problems fell by the wayside. I'm not qualified
> to judge this in the context of jpeg-turbo, much less contribute such a
> patch, but it did provide an escape from the low-level tooling problems.

It all boils down to the quality of the generated NEON code from
intrinsics. SIMD optimizations are very important for libjpeg-turbo
and provide a significant speed-up, making jpeg processing several
times faster.

And as far as I know, libpng is mostly limited by zlib performance and
does not gain that much from SIMD. So having the optimized assembly code
indeed may be not worth all the hassle.

But I understand that if you can readily accept the ~20% performance
loss from switching to clang, then any potential extra performance loss
in the SIMD part of the code is likely to be also good enough for you.
Somebody just needs to contribute the alternative intrinsics based
implementation and benchmark it.

-- 
Best regards,
Siarhei Siamashka

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

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

On 4/6/14 1:52 PM, Siarhei Siamashka wrote:
> It all boils down to the quality of the generated NEON code from
> intrinsics. SIMD optimizations are very important for libjpeg-turbo
> and provide a significant speed-up, making jpeg processing several
> times faster.
>
> And as far as I know, libpng is mostly limited by zlib performance and
> does not gain that much from SIMD. So having the optimized assembly code
> indeed may be not worth all the hassle.
>
> But I understand that if you can readily accept the ~20% performance
> loss from switching to clang, then any potential extra performance loss
> in the SIMD part of the code is likely to be also good enough for you.
> Somebody just needs to contribute the alternative intrinsics based
> implementation and benchmark it.

I am totally not interested in supporting two code paths that do the 
same thing.  I'd much rather continue supporting gas-preprocessor. 
Given that the specific problem we were having with it has been solved 
(and in fact was not a problem with gas-preprocessor at all-- it was a 
problem with my build instructions), this issue is now academic.

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

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

Yeah, but I'm assuming that apps still access dylibs provided by the 
O/S.  Those will be versioned differently depending on the O/S release.


On 3/28/14 9:27 AM, George King wrote:
> 3rd party dylibs are forbidden on iOS as part of their app store policy,
> so I don't think it matters.

Re: [Libjpeg-turbo-users] Unable to compile libturbo-jpeg for iOS devices with Xcode 5 / iOS 7

[George K. <gwk...@gm...>]

Right, sorry. I think you are correct about this.


On Fri, Mar 28, 2014 at 12:59 PM, DRC <dco...@us...>wrote:

> Yeah, but I'm assuming that apps still access dylibs provided by the
> O/S.  Those will be versioned differently depending on the O/S release.
>
>
> On 3/28/14 9:27 AM, George King wrote:
> > 3rd party dylibs are forbidden on iOS as part of their app store policy,
> > so I don't think it matters.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>