arm64编译优化
1. iOS armv7, armv7s, arm64区别与应用32位、64位配置
如果你不能确定库是否支持了arm64，可以在cmd模式下用file命令来检查一下库文件：
armv7，armv7s和arm64,i386,x86_64这些都代表什么？
__Arm处理器，因为其低功耗和小尺寸而闻名，几乎所有的手机处理器都基于arm，其在嵌入式系统中的应用非常广泛，它的性能在同等功耗产品中也很出色。
Armv6、armv7、armv7s、arm64都是arm处理器的指令集，所有指令集原则上都是向下兼容的，如iPhone4S的CPU默认指令集为armv7指令集，但它同时也兼容armv6指令集，只是使用armv6指令集时无法充分发挥其性能，即无法使用armv7指令集中的新特性，同理，iPhone5的处理器标配armv7s指令集，同时也支持armv7指令集，只是无法进行相关的性能优化，从而导致程序的执行效率没那么高。
现在回归到正题，如何制作一个“没有问题”的.a静态库，通过以上信息了解到，当我们做App的时候，为了追求高效率，并且减小包的大小，Build Active Architecture Only设置成YES，Architectures按Xcode默认配置就可以，因为arm64向前兼容。但制作.a静态库就不同了，因为要保证兼容性，包括不同iOS设备以及模拟器运行不出错，所以结合当前行业情况，要做到最大的兼容性。
ValidArchitectures设置为：armv7｜armv7s｜arm64｜i386｜x86_64
Architectures设置不变（或根据你需要）: armv7｜arm64
然后分别选择iOS设备和模拟器进行编译，最后找到相关的.a进行合包:
使用lipo -create 真机库.a的路径 模拟器库.a的的路径 －output 合成库的名字.a ，这样就制作了一个通用的静态库.a。
制作动态、静态库详情可以参考 【链接】
部份资源 链接
2. 如何对静态库编译增加arm64的支持
之前app用到的libmp3lame.a静态库，也要支持64位的模拟器(x86_64)和64位的真机(arm64）指令集。需要重新编译
查阅了下资料，按照如下步骤，并做了些注释和改动
1.http。//sourceforge。net/projects/lame/files/lame/3.99/ 下载lame的最新版本解压到一个文件夹里例如 lame，全路径如下/Users/8wm/Desktop/lame
2.下载build的脚本，我这里使用的是国外一个朋友的分享
https。//github。com/kewlbear/lame-ios-build
下载之后得到lame-build.sh拷贝到文件夹/Users/8wm/Desktop/lame
3.用bbedit或者其他编辑器打开这个脚本，按照注释修改
4.打开Terminals，
输入
cd /Users/8wm/Desktop/lame
chmod 777 lame-build.sh
sudo -s#
输入系统密码
./lame-build.sh
开始编译，编译完成之后。生成fat-lame目录和thin-lame目录，分别存放合并所有指令集的静态库，以及各指令集的静态库.
根据所需， lame.h和libmp3lame.a文件到project里，就可以正常使用了。
可以使用命令行，查看换个库支持的指令集。
lipo -info libmp3lame.a
Architectures in the fat file: libmp3lame.a are: armv7 armv7s i386 x86_64 arm64
以下是build的脚本，请注意黄色的字和注释。
#!/bin/sh
make distclean
CONFIGURE_FLAGS="--disable-shared --disable-frontend"
ARCHS="arm64 armv7s x86_64 i386 armv7"
# directories
# SOURCE是下载lame源码包，解压后的目录，可以把sh脚本放到这个目录，source改为""
SOURCE=""
# FAT是所有指令集build后，输出的目录，所有静态库被合并成一个静态库
FAT="fat-lame"
# SCRATCH是下载lame源码包，解压后的目录，必须是绝对路径
SCRATCH="/Users/8wm/Desktop/lame"
# must be an absolute path
# THIN 各自指令集build后输出的静态库所在的目录，每个指令集为一个静态库
THIN=`pwd`/"thin-lame"
COMPILE="y"
LIPO="y"
if [ "$*" ]
then
if [ "$*" = "lipo" ]
then
# skip compile
COMPILE=
else
ARCHS="$*"
if [ $# -eq 1 ]
then
# skip lipo
LIPO=
fi
fi
fi
if [ "$COMPILE" ]
then
CWD=`pwd`
echo "$CWD/$SOURCE........."
for ARCH in $ARCHS
do
echo "building $ARCH..."
mkdir -p "$SCRATCH/$ARCH"
cd "$SCRATCH/$ARCH"
if [ "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]
then
PLATFORM="iPhoneSimulator"
if [ "$ARCH" = "x86_64" ]
then
SIMULATOR="-mios-simulator-version-min=7.0"
HOST=x86_64-apple-darwin
else
SIMULATOR="-mios-simulator-version-min=5.0"
HOST=i386-apple-darwin
fi
else
PLATFORM="iPhoneOS"
SIMULATOR=
HOST=arm-apple-darwin
fi
XCRUN_SDK=`echo $PLATFORM | tr '[:upper:]' '[:lower:]'`
CC="xcrun -sdk $XCRUN_SDK clang -arch $ARCH"
#AS="$CWD/$SOURCE/extras/gas-preprocessor.pl $CC"
CFLAGS="-arch $ARCH $SIMULATOR"
CXXFLAGS="$CFLAGS"
LDFLAGS="$CFLAGS"
CC=$CC $CWD/$SOURCE/configure \
$CONFIGURE_FLAGS \
--host=$HOST \
--prefix="$THIN/$ARCH" \
CC="$CC" CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS"
make -j3 install
cd $CWD
done
fi
if [ "$LIPO" ]
then
echo "building fat binaries..."
mkdir -p $FAT/lib
set - $ARCHS
CWD=`pwd`
cd $THIN/$1/lib
for LIB in *.a
do
cd $CWD
lipo -create `find $THIN -name $LIB` -output $FAT/lib/$LIB
done
cd $CWD
cp -rf $THIN/$1/include $FAT
fi
3. Undefined symbols for architecture arm64…
Undefined symbols for architecture arm64(其cpu架构)
" OBJC_CLASS $_XXX",referenced from: 之类的问题，很多人看到这些很头疼，不知道从何下手去修改。以下是我总结的相关修改办法。如下图
这是一个在arm64架构下，找不到定义的错误。 这类错误我总结的就六种，.m 缺失、静态库没导入(不支持arm64 架构，现在基本都支持了，如果不支持更新相关静态库。怎么查看参考文末)、library路径问题、header 文件路径、Valid Architectures 指定错误，连接器参数问题
1.那么首先检查 Architectures 选项
通常情况下，Build Active Architectures Only 在Debug 模式为YES,Release模式为NO。
Valid Architectures 为 arm64 armv7 armv7s
需要你了解的是 只有连接了Active 的调试设备，这个选项才生效，只编译当前设备对应的指令集。如果你没有连接设备，那么这里即使是YES，也不会生效。编译器会按照你的Valid Architectures和Architectures指定的二进制包进行编译。
具体参考
armv6 设备： iPhone, iPhone2, iPhone3G, 第一代、第二代 iPod Touch
armv7 设备： iPhone3GS, iPhone4, iPhone4S
armv7s设备： iPhone5, iPhone5C, iPad4(iPad with Retina Display)
arm64 设备： iPhone5S, iPad Air, iPad mini2(iPad mini with Retina Display) 之后出的到X都是arm64的设备了
2. 向 Link Binary With Libraries 中 添加相应的framework ，向Compile Source 添加你缺失的.m
3.修改 Other Linker Flags 添加 -ObjC 和 $(inherited)，（也可以直接添加缺失的framework 如： -framework "frameworkname" ）
4. Header Search Path 和Library Search Path 先添加$(inherited)，如果编译后，没有出现，就手拖缺失文件的相关路径（如果路径为多层级，选择递归搜索recursive 默认是non-recursive）
5.最后检查 framework 和.m 有没有 勾选 target membership 。
总之，如果先思考是静态库问题，还是其他文件问题，会节约很多时间。以上总结，以留档备查，也希望可以给别人一些思路。
实例 1： 错误信息中有明显的提示 does not contain bitcode。 所以 直接设置 bitcode 为NO 就可以了
查看.a或.framework 的静态库文件都支持哪些架构， 终端 进入工程根目录 find . -name *.a -exec lipo -info "{}" 或者.framework
4. ARMClang6.1编译优化导致的访问不对齐异常
keil-project-options for target-选项卡c/c++ 左侧中间有个optimization 后面的对应的就是编译优化设置 level 0就是不优化
5. arm-linux-gcc交叉编译器的制作，以及版本选择问题。
，需要必须有足够动经验来支持。
另外，用 RH9 的都是高手，我想你的知识不需要来提问了吧？
1、在 PC 上编译 arm 的程序当然需要较差编译器，这个需要自己安装，或者着现成的交叉编译器环境，一般是一个特殊参数编译出来的 gcc + binutils + glibc + linux-header。这个每个人动环境不同，一般都需要自己编译一个，当然没有特殊需求，也可以找现成的。不过很难找，因为这套环境还要和你动系统搭配，不然环境不匹配，连这个环境都不能运行，那就更谈不上编译东西了。
有关自己编译搭建交叉编译环境，可以看看一个特殊的 Linux 发行版 LFS 的分支： CLFS 。
2、移植分很多意思，移植有可能就意味着这套源代码不能在目标系统上面编译，需要你根据相应的知识去修改源代码来让这套代码适应目标编译器的要求，比如源代码有 SSE4 的优化，这套程序在非 SSE4 CPU 上无法编译运行，但目标机器连 SSE1 都不支持。那么就需要移植。
或者移植仅仅是根据新的环境进行编译，不需要进行源代码修改，只需要进行一下编译就能运行的程序，也可以称为移植，就是从一个环境、架构 -》另一个环境、架构。都可以称为移植，但真正的移植意味着修改程序源代码来适应新环境。你说的这种移植是最简单的移植。
3、决定目标硬件环境 -》搭建目标编译器 -》制作目标环境（内核，基础软件库）-》进行应用移植（移植需要的软件、主应用程序）-》搭建系统文件系统 -》导入目标系统-》启动目标系统&应用。说起来很简单，因为这是完全没有问题的条件下。
至于超级终端。那是用来控制目标系统的。目标系统有可能不能插键盘鼠标显示器，这就需要一个远程网络链接来进行控制。以及通过远程链接来发送数据。这都需要终端的支持。
虚拟机下面进行开发，不能发挥你的计算机的性能。而且因为隔着 VMware 的软件模拟层，可能还不会很方便的让你链接目标设备。
至于用 socket ，我还没见到你的目标需要这个东西，因为所有的东西都是现成的源代码。不需要你从 0 开始写，当然你想自己写一个系统内核，或者服务器程序，或者全套的系统+应用，我绝对不拦你，但希望你写完这套东西，能把源代码发布出来。
ads 可以认为是一个支持环境，他本身不是一个系统的开发 SDK 。
-------------------------------------
ads 没用过，印象里他还有模拟器，调试器什么的程序。功能上要比 Linux 开发环境，WinCE 环境下面的东西更多更偏向于硬件方面，毕竟 ads 是 arm 出品的，不太可能偏向于软件部分设计。Linux 和 WinCE 都是系统而不是硬件工具。
你可以认为交叉编译器是一个应用程序，一个输出器。把源代码输出为 arm 的代码，这个应用程序的输出，是靠他自己的环境，而不是当前系统的环境的。
当前系统的各个软件的版本，不能影响交叉编译器输出的环境（理论上，现实有的时候总是从别的地方给你打击……），交叉编译器一般至少有 gcc 、binutils 、glibc 库、linux kernel 头文件。
在软件需求上。
头文件谁都不依赖，glibc 只需要内核头文件，其他程序全都依赖于 glibc 。也就是所有程序都不依赖内核，仅仅是依赖于内核头文件。
gcc 和 binutils 是把程序源代码根据上面各个环节的需提供的功能来输出为上面环节里面的二进制程序。依赖你当前环境的，只有 gcc 和 binutils 两个程序的执行、控制环节。只有他们两个依赖的，而不是你的交叉编译后的程序。
至于编译器版本的选择，新版本功能更好，旧版本兼容更好。
这个要看你的实际需要了。应用程序源代码也调编译器的，同时也依赖于软件库的功能。
arm 开发建议稳定、兼容优先。当然也可以尝试最新的编译环境，来获取更好的优化（前提是还有什么代码优化的话）。
另外,团IDC网上有许多产品团购,便宜有口碑