解决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 handling disabled, use -fexceptions toenable。

问题解决：

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

补充：

  AndroidNDK r5对C++的支持情况

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

1、C++的异常支持：

    从NDK r5就开始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 Type Information）了。但是，为了通用性的，所有的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 Library Implementation:

By default, theheaders and libraries for the minimal C++ runtime system
library (/system/lib/libstdc++.so) are used when building C++ sources.

You can howeverselect a different implementation by setting the variable
APP_STL to something else in your Application.mk, for example:

  APP_STL:= stlport_static

To select thestatic STLport implementation provided with this NDK.
Value APP_STL values are the following:

   system              ->Use the default minimal C++ runtime library.
   stlport_static      -> UseSTLport built as a static library.
   stlport_shared      -> UseSTLport built as a shared library.

WARNING:IMPORTANT CAVEAT

     ATTHE MOMENT, OUR STLPORT IMPLEMENTATION DOES NOT SUPPORT EXCEPTIONS
     AND RTTI. PLEASE BE SURE TO NOT USE -fexceptionsOR -frtti IN ALL
     MODULES THAT USE IT.

WARNING: END OFIMPORTANT CAVEAT

  "stlport_shared"is preferred if you have several shared libraries in your
  project that use the C++ STL, because it avoids duplication offunctions
  and more importantly of global variables (e.g. std::cout) in eachone of
  them, which can have surprising results.

  Onthe other hand, you will have to load it explicitely when starting your
  application, as in the following example:

     static{
         System.loadLibrary("stlport_shared");
         System.loadLibrary("foo");
         System.loadLibrary("bar");
     }

  Whereboth "libfoo.so" and "libbar.so" depend on"libstlport_shared.so".

  Notethat the shared library's name if "libstlport_shared.so" to avoid
  naming conflicts with certain Android system images which include a
  system-level libstlport.so (which happens to not be ABI-stable and
  cannot be used from NDK-generated machine code).

  "stlport_static"is preferred if you have only one shared library in your
  project: only the STL functions and variables you actually needwill be
  linked to your machine code, reducing its code size, and you won'tneed
  to load the dynamic stlport_shared at startup.

IV. STLport-specific issues:
----------------------------

This NDKprovides prebuilt static and shared libraries for STLport,
but you can force it to be rebuilt from sources by defining the following
in your environment or your Application.mk before building:

    STLPORT_FORCE_REBUILD:= true

STLport islicensed under a BSD-style open-source license. See
sources/cxx-stl/stlport/README for more details about the library.

V. Future Plans:
----------------

  -Make STLport compatible with C++ exceptions and RTTI
  - Full GNU libstdc++ support