解决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