解決NDK出現error: exception handling disabled, use ...

本文出自：http://drovik.com/html/8410924155.html

 

問題來源：

 

   UDT的android平臺移植過程當中，在用NDK編譯buffer.cpp文件時出現error: exception handling disabled, 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++)以及與之對應的頭文件。

一、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是不支持異常的。

 

二、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, 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 the variable
APP_STL to something else in your Application.mk, for example:

  APP_STL := stlport_static

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

   system              -> Use the default minimal C++ runtime library.
   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 SUPPORT EXCEPTIONS
     AND RTTI. PLEASE BE SURE TO NOT USE -fexceptions OR -frtti IN ALL
     MODULES THAT USE IT.

WARNING: END OF IMPORTANT CAVEAT

  "stlport_shared" is preferred if you have several shared libraries in your
  project that use the C++ STL, because it avoids duplication 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 it explicitely 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" depend on "libstlport_shared.so".

  Note that 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 need will be
  linked to your machine code, reducing its code size, and you won't need
  to load the dynamic stlport_shared at startup.

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

This NDK provides 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 is licensed 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