其实没什么好解决的，
忍了2年了
所以今天重新把所有代码，所有编译过程，重新看一遍
编译curl很多遍了，老是提示architecture x86_64
一开始以为是编译问题，还想用gcc重新编译
但是明显curl是一个第三方库，而它也是可能引用第第三方库
从上面截图可以看出
"_zlibVersion",referenced from:
_curl_version in lib curl.a
_curl_version_info in lib curl.a
_Curl_unencode_gzip_write in lib curl.a
明显的是用到zlib库（zip库）
所以看来还是得从zlib着手
（zlib的x86_64框架已编译通过）
－－－－－－－－－－－－2016.10.15
编译了几天，发现openssl又出问题了，网上下的所谓x86_64还是不行
所以还是自己编译吧，arm7和x86_64的openssl编译方法见下链接
macos编译提示 option -Bsymbolic
Bsymbolic完全不知道什么鬼，百度之，原因是：
The -Bsymbolic flag specified in the Makefile of that project is specific to the GNU linker and platforms using the ELF binary format. OS X uses neither. The Makefile has several other flags that aren't compatible with the OS X toolchain, such as the use of the .so extension for shared libraries rather than .dylib, and another unsupported linker flag (-Wl,-soname=…). You should be able to remove the unsupported linker flags and then fix up the file extensions to make things work.
-Wl,-Bsymbolic.
其中 Wl 表示将紧跟其后的参数，传递给连接器 ld 。 Bsymbolic 表示强制采用本地的全局变量定义，这样就不会出现动态链接库的全局变量定义被应用程序/动态链接库中的同名定义给覆盖了！
查到了病没有什么卵用，因为根本不知道怎么解决解决方法应该在这里
http://*.com/questions/7216973/is-there-a-downside-to-using-bsymbolic-functions
－－－－－－－－－－－－2016.10.19
又一个不错的openssl自下载，自编译库，可以参考一下，但请不要报侥幸心理，最好还是自己把编译过程搞懂（2000行左右的makefile代码），要不花的时间更多
http://www.andyibanez.com/quick-tip-compile-openssl-arm-arm64-ios/
编译提示
xxx.shared出错，实在找不到-Bsymbolic在哪里
后来终于在makefile.shared找到了这么一段，remark之
#SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared -Wl,-Bsymbolic -Wl,-soname=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX"
DO_GNU_SO_COMMON=\
SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared -Wl,-soname=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX"
编译提示
xxx.shared出错，虽然找到了-soname在哪里
但实在奇怪的是mac iphone的动态库是dylib 而不是so
“
This is strange, as Mac has .dylib extension instead of .so.
其实歪果仁真的是大惊小怪，以我的理解，so是静态库，静态库
解决方法：
I had a similar issue on OS X which I resolved using the the install_name switch instead of soname.
gcc -shared <files> -lc -Wl,-install_name,<libname>.so, -o <libname>.so.1
xxx.shared出错，现在是--whole-archive
首先 --whole-archive 和 --no-whole-archive 是ld专有的命令行参数，gcc 并不认识，要通gcc传递到 ld，需要在他们前面加 -Wl，字串。
--whole-archive 可以把 在其后面出现的静态库包含的函数和变量输出到动态库，--no-whole-archive 则关掉这个特性。
比如你要把 liba.a libb.a libc.a 输出到 libabc.dll(或libabc.so)时应该这么写：
libabc.dll:liba.c libb.a libc.a
gcc -shared -o $@ -L. -Wl,--whole-archive -la -lb -lc -Wl,--no-whole-archive
在--whole-archive作用下的库里不能有函数同名。
xxx.shared出错，这下好了，直接就说缺了x86_64
这个问题解决方法反而简单，有连续看我博客的都知道，要是你真的觉得自己是程序猿不要抱有侥幸心理，还是从源头搞起，这个问题这里出现了，总比在你自以为编译成功了，然后放到真机调试，出现摸不着头脑的问题，又或者你自以为成功，乐于开源，上传到网上说这是x86_64的版本，而坑到别人，其实这个库的第三方库根本就有问题（我被坑不少，不知道你们程序猿如何）