ia32 option for iOS does not produce i386 lib
Closed this issue · 7 comments
GoogleCodeExporter commented
What steps will reproduce the problem?
1. Compiling with the ia32 setting for iOS produces a x86_64 library
What is the expected output? What do you see instead?
When compiling with ia32 I expect the i386 lib but receive the 64bit version.
What version of the product are you using? On what operating system?
yuv trunk on OS-X using xcode 8.3 tools.
Please provide any additional information below.
It is most likely just a minor detail in the build script but our iOS devs
wants to maintain the possibility to use the older iOS simulators so we really
need the i386 builds to build as well.
All other options, armv7, armv7s, arm64 and x86_64 works fine.
Original issue reported on code.google.com by ilantzco...@gmail.com
on 25 Jun 2015 at 11:12
- Blocked on: #456
GoogleCodeExporter commented
currently blocked on bug 456 - can't build on ios.
the ia32 behavior is likely defined by the chromium dependencies. if you could
track back to the last good version, we could try rolling chromium deps back to
that
Original comment by fbarch...@google.com
on 26 Jun 2015 at 9:43
- Now blocked on: #456
GoogleCodeExporter commented
I just posted a solution for that problem in issue 456.
Original comment by kjellan...@google.com
on 28 Jun 2015 at 7:06
GoogleCodeExporter commented
When did this last work for ia32?
Try rolling back chromium deps to an older version?
Original comment by fbarch...@google.com
on 29 Jun 2015 at 5:49
GoogleCodeExporter commented
The Getting started doesnt show the simulator settings. Starting with arm 64
bit:
arm64
GYP_DEFINES="OS=ios target_arch=armv7 target_subarch=64" GYP_CROSSCOMPILE=1 GYP_GENERATOR_FLAGS="output_dir=out_ios" ./gyp_libyuv -f ninja --depth=. libyuv_test.gyp
ninja -j7 -C out_ios/Debug-iphoneos libyuv_unittest
we get 64 bit arm as expected
bash-3.2$ file ./out_ios/Release-iphoneos/libyuv_unittest.app/libyuv_unittest
./out_ios/Release-iphoneos/libyuv_unittest.app/libyuv_unittest: Mach-O 64-bit
executable
Do 32 similulator like this:
GYP_DEFINES="OS=ios target_arch=ia32 target_subarch=32" GYP_CROSSCOMPILE=1
GYP_GENERATOR_FLAGS="output_dir=out_sim" ./gyp_libyuv -f ninja --depth=.
libyuv_test.gyp
ninja -j7 -C out_sim/Debug-iphonesimulator libyuv_unittest
bash-3.2$ file
./out_sim/Debug-iphonesimulator/libyuv_unittest.app/libyuv_unittest
./out_sim/Debug-iphonesimulator/libyuv_unittest.app/libyuv_unittest: Mach-O
universal binary with 2 architectures
./out_sim/Debug-iphonesimulator/libyuv_unittest.app/libyuv_unittest (for
architecture i386): Mach-O executable i386
./out_sim/Debug-iphonesimulator/libyuv_unittest.app/libyuv_unittest (for
architecture x86_64): Mach-O 64-bit executable x86_64
Original comment by fbarch...@google.com
on 30 Jun 2015 at 11:16
- Changed state: Accepted
GoogleCodeExporter commented
webrtc documents parts of the build
without target_subarch=32 it produces only the x86_64 version.
with target_subarch=32 it produces both and uses lipo to join them.
I've updated Getting Started
Original comment by fbarch...@google.com
on 1 Jul 2015 at 12:00
- Changed state: Fixed
GoogleCodeExporter commented
I have more information on this. arm had the same issue:
https://code.google.com/p/libyuv/issues/detail?id=467
Looking in common.gypi there is a behavior change for arch/subarch to default
to 64 bit
Its not well documented, but you can determine the valid setting from this
snippet:
# Limit the valid architectures depending on "target_subarch".
# This need to include the "arm" architectures but also the "x86"
# ones (they are used when building for the simulator).
['target_subarch=="arm32"', {
'VALID_ARCHS': ['armv7', 'i386'],
}],
['target_subarch=="arm64"', {
'VALID_ARCHS': ['arm64', 'x86_64'],
}],
['target_subarch=="both"', {
'VALID_ARCHS': ['arm64', 'armv7', 'x86_64', 'i386'],
}],
for 32 bit arm
target_arch=i386
target_subarch=arm32
I updated the Getting Started
Original comment by fbarch...@google.com
on 15 Jul 2015 at 10:09
- Changed state: Started
GoogleCodeExporter commented
Original comment by fbarch...@chromium.org
on 22 Jul 2015 at 10:37
- Changed state: Fixed