Drop armv7s and i386 as targets?

[Bruno]

Dear All,

I'm interested in hearing if anyone cares about armv7s and i386 as architecture targets for J2ObjC library builds or for the Gradle Plugin? I'm arguing for dropping both of them.

armv7s

This was deprecated in Xcode 6 as a “standard architecture”. It provides a very small performance improvement compared to armv7.

See: http://stackoverflow.com/a/25398898/1509221

i386

This is for running the iOS simulator on a 32-bit Mac OS X machine. The last a Mac was sold that couldn't run a 64-bit application was 2011 (source) and developers typically have much more recent machines. Such that I think it very unlikely that a developer needs 32-bit support.

The remaining targets are:

1) x86_64 - needed for the iOS simulator on modern 64-bit Macs

2) armv7 - 32-bit iPhones, like the 5c and earlier

3) arm64 - 64-bit iPhones, like the 5s and later

Submitting to the app store requires both armv7 and arm64 support.

Bruno

[Daniel Zlotin]

For helpful reference:

http://iossupportmatrix.com/

1.Are there any side effects for not building for armv7s? I mean can we still run on iPhone5(2012) and iPad(2012)? I will love to see the speed of the build script improved :)

And if we are already on the subject:

Checking my build script (taken from j2objc source), I see I build with these -arch flags: armv7, arm64, armv7s, i386, and another one without -arch flag.

2. As I lazily copied this, what is this last arch with the -arch flag? specifically this line compiles to what architecture?:

j2objcc -I . -I ../Quando_LibHeaders -c -fobjc-abi-version=2 -fobjc-legacy-dispatch -fobjc-arc `find . -name *.m`

3. Should I replace the i386 with x86_64? will it make any difference?

Thanks

[Keith Stanger]

For the record, if you are building j2objc from source, you can speed it up by defining J2OBJC_ARCHS in your environment to specify the architectures you care about. See https://github.com/google/j2objc/blob/master/make/common.mk#L39

--
You received this message because you are subscribed to the Google Groups "j2objc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bruno]

On Wed, Sep 2, 2015 at 7:02 AM 'Keith Stanger' via j2objc-discuss <j2objc-...@googlegroups.com> wrote:

For the record, if you are building j2objc from source, you can speed it up by defining J2OBJC_ARCHS in your environment to specify the architectures you care about. See https://github.com/google/j2objc/blob/master/make/common.mk#L39

On Wed, 2 Sep 2015 at 09:30 Daniel Zlotin <zlotin...@gmail.com> wrote:

For helpful reference:

http://iossupportmatrix.com/

1.Are there any side effects for not building for armv7s? I mean can we still run on iPhone5(2012) and iPad(2012)? I will love to see the speed of the build script improved :)

Absolutely the armv7s devices (iPhone 5, 5c and 2012 iPad) can all run armv7 code. It seems like there only marginal value to have the armv7s slice, with some improvements in VFPv4 floating point support and integer division (ref).

Apple removed armv7s in Xcode 6 because it was of such limited value. We should do the same. If you do have a performance issue that benefits from armv7s support, then you've got an even bigger problem on the iPhone 4S and earlier. In which case, I think your effort is better spent on optimization.

 

And if we are already on the subject:

Checking my build script (taken from j2objc source), I see I build with these -arch flags: armv7, arm64, armv7s, i386, and another one without -arch flag.

I think you're talking about x86_64.

2. As I lazily copied this, what is this last arch with the -arch flag? specifically this line compiles to what architecture?:

j2objcc -I . -I ../Quando_LibHeaders -c -fobjc-abi-version=2 -fobjc-legacy-dispatch -fobjc-arc `find . -name *.m`

You're talking about this line?

    FAT_LIB_MACOSX_FLAGS = $(FAT_LIB_OSX_FLAGS) -DJ2OBJC_BUILD_ARCH=x86_64 \

    -isysroot $(FAT_LIB_MACOSX_SDK_DIR)

3. Should I replace the i386 with x86_64? will it make any difference?

I'm wondering about i386... I think it might be possible to use it for a 32-bit version of the iOS simulator. However, this is hard to setup and I'm doubtful about whether has actually used it this way.

This SO answer indicates that the iOS simulator is only 64-bit now but that you can force it to run a 32-bit build.

http://stackoverflow.com/a/23026056/1509221

My impression is that very rarely will someone need to do this. You can also always test the 32-bit app on an iPhone 4S (which you should be doing anyway). Again, I'd suggest i386 as it's of such little use. Then if someone really cares about it, they can build it themselves.

[Bruno]

Advay and I have elected to remove the armv7s and i386 architecture targets from the J2ObjC Gradle Plugin. We'll see how the next release (0.5) is received. If there isn't any negative issues reported, I'll file an issue against J2ObjC suggesting to remove the same targets.

PR to remove support in the plugin:

https://github.com/j2objc-contrib/j2objc-gradle/pull/448

[Advay Mengle (https://github.com/advayDev1)]

To be specific, we've removed default support for armv7 and i386.  You can always re-enable support if you need it with a line like:

j2objcConfig {

supportedArchs = NativeCompilation.ALL_SUPPORTED_ARCHS

[Tom Ball]

On the j2objc side -- Xcode 7 requires that we split out the Mac OS X builds from our fat libraries, since it now checks whether the x86_64 build was built for the iOS simulator when you start up a simulated 64-bit device such as iPhone 6. The armv7s was removed as you suggested. We kept the i386 build, though, because otherwise selecting 32-bit simulator models like the iPhone 5 fails with a scary error message. So until Xcode drops the 32-bit simulator options, we'll keep the i386 build.

[Bruno]

Tom, can you explain more about why you need to separate out the Mac OS X build? Presumably that'll affect the plugin as well.

Now I having second thoughts about whether we should keep the i386 build... Also I can imagine a lot of this changing again with Bitcode.

[Tom Ball]

Both the Mac OS X and iPhone simulator use x86_64 archs, when the chosen simulated model is a 64-bit device (like iPhone 6). Prior to clang 7.0.0 (distributed with Xcode 7), an x86_64 arch could be used to link either a Mac command-line or a simulator build. So in our fat libraries we had the x86_64 build doing double duty.

With Xcode 7's clang, the SDK used to build the library is checked, and iPhone simulator builds are failing with 64-bit devices. We therefore need an x86_64 library built using a MacOSX.platform for command-line apps, and another x86_64 built with an iPhoneSimulator.platform. The lipo utility combines all the arch-specific libraries into a fat library, but it won't allow two builds with the same arch in the same fat binary.

Since j2objc's focus is on iOS while command-line apps are just for convenience (like running device-independent tests), it made the most sense to keep the iOS libraries together in the fat library, and split off the command-line ones.

Your plug-in can probably use the same trick j2objcc.sh does: check for an iOS -isysroot flag and if not found, append macosx to the library path:

• No -isysroot flag: -L dist/lib/macosx
• "MacOSX" in sys root path: : -L dist/lib/macosx
• Otherwise, assume iOS: : -L dist/lib

[Bruno]

This'll definitely affect the plugin as well.

Advay - how much of an issue will this be?

[Advay Mengle (https://github.com/advayDev1)]

Bruno - can you file an issue and we can continue the discussion there?  We will need to handle it but the implementation should affect only us.