欢迎留言、转载请注明出处
最近在搞一个依赖了开源库fftw（写此文时用的官网最新发布版3.3.10，https://www.fftw.org/fftw-3.3.10.tar.gz）的代码，项目使用cmake构建，fftw依赖以子项目的方式引入：
add_subdirectory(dep/fftw-3.3.10)
测试后发现调用代码使用的是float版的接口，也就是需要通过设置“ENABLE_FLOAT”这个选项来编译fftw，参见：
set (FFTW_VERSION 3.3.9)
set (PREC_SUFFIX)
if (ENABLE_FLOAT)
set (FFTW_SINGLE TRUE)
set (BENCHFFT_SINGLE TRUE)
set (PREC_SUFFIX f)
endif ()
由于这个是调用代码的刚需，所以不想通过cmake命令行传递此设置，于是想到了再add_subdirectory前临时设置下这个选项，如下：
Continue reading…正常来说，cmake都是自己安装的，所以装在哪自己心里还是知道的。但是，如果cmake不是自己装的，或者是其它程序里集成的呢？比如CLion就bundle了很新版本的cmake，这时鸡贼的我在装了CLion的Mac系统上就想直接现成的cmake来build开源项目…
然后，尴尬的事就来了：我并不知道CLion自带的cmake在什么位置，找了下Library，CLion的app包内等常见位置，都没有发现自带cmake的踪影，于是搜索引擎调查了下，发现了这么个技巧：
Continue reading…今天记录一个个人觉得有点意思的问题：在C++代码中调用C API时，对于C回调函数的处理问题，如何识别出调用API时的信息？
这个问题，大部分API都是通过调用时提供传递用户数据的方式实现的，如libcurl中的CURLOPT_WRITEDATA，CURLOPT_READDATA ，通过curl_easy_setopt方式将任意用户数据指针传递给CURL句柄，并在执行上传下载时的回调函数内透传给调用方，这样在例如多线程并发上传下载时就可以很方便的识别出是哪个上传下载任务的回调了。但是，如果API及回调函数内没有提供传递用户数据的接口和回调参数的话，是不是就一定无法完成识别调用上下文信息的功能呢？比如下列的C函数API：
// C-Style callback function without user context
typedef void (*c_api_callback_no_context)(int count);
// C-Style callback function with user context
typedef void (*c_api_callback_context)(int count, void * user_context);
// C API function that will trigger the callback function
void c_api_start_counting_no_context(c_api_callback_no_context callback, int max);
void c_api_start_counting_context(c_api_callback_context callback, int max, void * user_context);
c_api_start_counting_context及配套的c_api_callback_context回调为可以透传用户数据的版本，而c_api_start_counting_no_context及c_api_callback_no_context则只提供了逻辑用回调参数count，没有可用于识别context的用户数据指针，那么如何在不碰C源码的前提下(闭源C库或不想做侵入式修改)做到和带用户数据回调一样的效果呢？目前想到的一种方法是通过C++模板生成不同地址的回调函数配合上下文信息映射来实现：
Continue reading…
自从Google抛弃Eclipse ADT转投IntelliJ IDEA搞出Android Studio后，Android的开发调试环境可以说是日臻完善，先是Android Studio 2.x加入了调试原生C/C++代码的功能，一解Android NDK开发调试不方便之困（想当年可是拜ndk开发调试所赐才熟练掌握了gdb命令行的各种操作…），现在的3.x又加入了直接调试任意apk中Java和native .so的功能：
测试了下，虽然过程中遇到了个小问题，不过最终还是成功了，基本能和AS开发的带C++ Support项目原生调试体验一致。下面记录下这个”小问题“的解决方法：
先说明下这个小问题是用AS调试任意apk中的.so时找不到调试符号，且无法定位到源码并命中断点的问题，也就是说是有源码调试！无源码调试理论上应该也可以，但不在本次研究范围之内。
Continue reading…
由于新版Android Studio的native调试功能实在是太好用了，所以试了下把旧版Cococs2d-x项目（大概是2.x版本吧）重建Android Studio项目。花了很长时间添加各种source，static library，prebuilt library以后，终于项目可以在Android Studio的cmake编译工具下成功编译链接并生成.so了，迫不及待的一运行，发现直接闪退，检查后发现是”Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeOnResume”这个cocos2d-x的jni函数没有找到！
初步检查了下，发现cmake编译出的cocos2d静态库.a中存在这个函数符号，但是最终生成的.so中确实是没有这个函数(使用ndk toolchain里面的nm)，于是想到应该是链接时认为这个符号没有代码调用，被stripe掉了。
后来又仔细看了下Android.mk，发现玄机貌似在于
LOCAL_WHOLE_STATIC_LIBRARIES += cocos2dx_static
对cocos2dx的静态库使用了WHOLE的链接方式，于是开始查找同样功能在cmake中的实现方式，最后查的结果如下：
Continue reading…