ios build:merge libyuv_neon.a and libyuv.a?build armv7s?

[GoogleCodeExporter]

What steps will reproduce the problem?

1、I success to build libyuv for ios version,but I found it has two 
lib(libyuv.a and libyuv_neon.a),Can I merge them? Is libyuv.a include 
libyuv_neon.a?

2、I need to build armv7s for ios,how to do?when I build arm64 for ios follow 
"Getting Start",I found that arm7.a arm7s.a arm64.a in 
"out_ios/Debug-iphoneos/arch" folder,Can I use them directly?

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

Original issue reported on code.google.com by tuy...@gmail.com on 14 Oct 2014 at 3:00

[GoogleCodeExporter]

Re 1 - 2 libs
Yes they can be merged.  It was done this way to allow different build options 
for the neon code vs arm code.
The mechanism for building with different options per file doesnt work on 
Android.
Its less useful on iOS, where all models since iPhone3gs have Neon, and arm64 
requires neon.
I can think of 4 solutions.
1. a post build merge could be done.
2. check for ios or 64 bit and add the neon/neon64 files to libyuv.a instead of 
libyuv_neon.a
3. use attribute to specific neon per function on newer compilers
4. use -Wa, to tell assembly to use neon.
5. drop 'fat binary' support.  build with neon or without but not a mix.

Re 2 armv7s
I see the same thing, but I dont know the answer.  When I asked chromium for 
armv7s builds about 3 months ago they said it would be infeasible to have 3 
variations.  This is the bug for that
https://code.google.com/p/libyuv/issues/detail?id=316
Theres a chromium bug floating around too.  I'm told if you generate the build 
files, you can change the armv7 to armvs and then do the build.  The 
differences are minor - you get an integer divide, and more floating point 
support.
The arm64 files contain the content, and the others are empty.
In this bug I showed disassembly some of the arm64 files.
https://code.google.com/p/libyuv/issues/detail?id=319

I'll use this issue (371) for the single library.  Will explore the -Wa method.

Original comment by fbarch...@google.com on 14 Oct 2014 at 5:24

• Changed state: Accepted

[GoogleCodeExporter]

Is there a reason for your merge request?

Original comment by fbarch...@google.com on 15 Oct 2014 at 9:20

[GoogleCodeExporter]

-Wa is used now, but will not work on future clang versions that do not call an 
external assembler tool.
Unclear if its safe to proceed with a -Wa approach.

Original comment by fbarch...@google.com on 1 Nov 2014 at 1:11

• Changed state: Started

[GoogleCodeExporter]

Merging the 2 libs has some pros and cons.

pro
simplify build

con
wa feature is going away - will break llvm in future.

Unclear if we should proceed with unification.
Any feedback?

Original comment by fbarch...@google.com on 24 Nov 2014 at 7:35

• Changed state: New

[GoogleCodeExporter]

-Wa caused breakage on gcc 4.9.  So this has been disabled.
Another idea is when forcing neon to be required, a single library could be 
done.

This would simplify the library for aarch64 or for ios where neon is required.  
But would complicate making fat binaries where neon is optionally detected and 
supported but the code still runs on cpus without neon.

armv7s support via gyp is contingent on chromium build support. When I asked, 
the idea was shot down.  But this will change in the future, when arm7s becomes 
the minimum platform, or important enough to add.
No source code is affected, and I dont plan to add cpu detection for armv7s vs 
armv7.  If thats alright.

Original comment by fbarch...@google.com on 7 Jan 2015 at 7:23

[GoogleCodeExporter]

The neon library as is, doesnt build on non-arm hardware.  Would be good to 
sufficiently make this general purpose.

Original comment by fbarch...@google.com on 10 Feb 2015 at 2:20