解决NDK出现error: exception handling disabled, use -fexceptions to enable的问题

地址：http://blog.sina.com.cn/s/blog_643e838601015zbo.html

问题来源：

 

  UDT的android平台移植过程中，在用NDK编译buffer.cpp文件时出现error: exception handlingdisabled, use -fexceptions to enable。

 

问题解决：

  此问题的出现是编译器的异常异常捕获被禁用了，需要在Android.mk文件中开启。在Android.mk文件中添加：LOCAL_CPPFLAGS +=-fexceptions就可以了。或者在Application.mk文件中添加APP_CPPFLAGS +=-fexceptions

也是可以的。

 

补充：

  Android NDK r5对C++的支持情况

 android平台提供了一个最小化的C++运行库(/system/lib/libstdc++)以及与之对应的头文件。

1、C++的异常支持：

 

    从NDKr5就开始NDK的工具链就开始支持了C++的异常控制，只不过为了通用性的原因，所有的C++原文件被编译的时候都是默认的是-fno-exceptions，即不不支持异常控制的。

   使用-fexceptions标记可以开启异常控制。所以你只需要在你的每个模块的Android.mk中添加LOCAL_CPPFLAGS+= -fexceptions就可以了。

   更简单的是，在你的Application.mk文件中添加APP_CPPFLAGS +=-fexceptions，这种配置会自动应用到你工程的所有模块当中。

   注意:

    已被废弃的"arm-eabi-4.4.0"工具链提供的向后兼容的NDK是不支持异常的。

 

2、RTTI support:

   从NDK r5开始，NDK工具链也开始支持C++RTTI（Runtime TypeInformation）了。但是，为了通用性的，所有的C++源文件被构建的时候默认是不支持RRRI的（-fno-rtti）。需要开启的话，你需要在Android.mk中添加：LOCAL_CPPFLAGS+= -frtti，或者更简单的做法是在Application.mk添加APP_CPPFLAGS += -frtti。

   注意:

    已被废弃的"arm-eabi-4.4.0"工具链提供的向后兼容的NDK是不支持RTTI的。

 III. Selecting the C++ Standard LibraryImplementation:

By default, the headers and libraries for the minimal C++runtime system

library (/system/lib/libstdc++.so) are used when building C++sources.

You can however select a different implementation by setting thevariable

APP_STL to something else in your Application.mk, for example:

  APP_STL := stlport_static

To select the static STLport implementation provided with thisNDK.

Value APP_STL values are the following:

  system             -> Use the default minimal C++ runtimelibrary.

  stlport_static     -> Use STLport built as a static library.

  stlport_shared     -> Use STLport built as a shared library.

WARNING: IMPORTANT CAVEAT

    AT THE MOMENT, OUR STLPORT IMPLEMENTATION DOES NOT SUPPORTEXCEPTIONS

    AND RTTI. PLEASE BE SURE TO NOT USE -fexceptions OR -frtti INALL

    MODULES THAT USE IT.

WARNING: END OF IMPORTANT CAVEAT

  "stlport_shared" is preferred if you haveseveral shared libraries in your

  project that use the C++ STL, because it avoidsduplication of functions

  and more importantly of global variables (e.g.std::cout) in each one of

  them, which can have surprising results.

  On the other hand, you will have to load itexplicitely when starting your

  application, as in the following example:

    static {

        System.loadLibrary("stlport_shared");

        System.loadLibrary("foo");

        System.loadLibrary("bar");

    }

  Where both "libfoo.so" and "libbar.so" dependon "libstlport_shared.so".

  Note that the shared library's name if"libstlport_shared.so" to avoid

  naming conflicts with certain Android systemimages which include a

  system-level libstlport.so (which happens to notbe ABI-stable and

  cannot be used from NDK-generated machinecode).

  "stlport_static" is preferred if you haveonly one shared library in your

  project: only the STL functions and variablesyou actually need will be

  linked to your machine code, reducing its codesize, and you won't need

  to load the dynamic stlport_shared atstartup.

IV. STLport-specific issues:

----------------------------

This NDK provides prebuilt static and shared libraries forSTLport,

but you can force it to be rebuilt from sources by defining thefollowing

in your environment or your Application.mk before building:

   STLPORT_FORCE_REBUILD := true

STLport is licensed under a BSD-style open-source license.See

sources/cxx-stl/stlport/README for more details about thelibrary.

V. Future Plans:

----------------

  - Make STLport compatible with C++ exceptionsand RTTI

  - Full GNU libstdc++ support