# Misc library-related options

config CC_GCC_ENABLE_TARGET_OPTSPACE

    bool

    prompt "Optimize gcc libs for size"

    default y

    help

      Pass --enable-target-optspace to crossgcc's configure.

      This will compile crossgcc's libs with -Os.

config CC_GCC_USE_GRAPHITE

    bool

    prompt "Enable GRAPHITE loop optimisations"

    default y

    depends on CC_GCC_HAS_GRAPHITE

    select CC_GCC_USE_PPL_CLOOG

    help

      Enable the GRAPHITE loop optimsations.

      This requires the PPL and CLooG companion libraries, and

      those will be automatically build for you.

      On some systems (eg. Cygwin), PPL and/or CLooG may not

      build properly (yet), so you'll have to say 'N' here.

# The way LTO works is a bit twisted.

# See: http://gcc.gnu.org/wiki/LinkTimeOptimization#Requirements

# Basically:

#   - if binutils has plugins: LTO is handled by ld/gold by loading

#     the plugin when linking

#   - if binutils does not have plugins: LTO is handled by collect2

# In any case, LTO support does not depend on plugins, but takes

# advantage of it

config CC_GCC_USE_LTO

    bool

    prompt "Enable LTO"

    default y

    depends on CC_GCC_HAS_LTO

    select CC_GCC_USE_LIBELF

    help

      Enable the Link Time Optimisations.

      This will require the libelf companion library, and it

      wil be build automatically for you.

config STATIC_TOOLCHAIN

    select CC_STATIC_LIBSTDCXX if CC_GCC_4_4_or_later

config CC_STATIC_LIBSTDCXX

    bool

    prompt "Link libstdc++ statically into the gcc binary"

    default y

    depends on CC_GCC_4_4_or_later

    help

      Newer gcc versions use the PPL library which is C++ code.  Statically

      linking libstdc++ increases the likeliness that the gcc binary will

      run on machines other than the one which it was built on, without

      having to worry about distributing the matching version of libstdc++

      along with it.

config CC_GCC_LIBMUDFLAP

    bool

    prompt "Compile libmudflap"

    default n

    help

      libmudflap is a pointer-use checking tool, which can detect

      various mis-usages of pointers in C and (to some extents) C++.

      You should say 'N' here, as libmduflap generates instrumented

      code (thus it is a bit bigger and a bit slower) and requires

      re-compilation and re-link, while it exists better run-time

      alternatives (eg. DUMA, dmalloc...) that need neither re-

      compilation nor re-link.

config CC_GCC_LIBGOMP

    bool

    prompt "Compile libgomp"

    default n

    help

      libgomp is "the GNU implementation of the OpenMP Application Programming

      Interface (API) for multi-platform shared-memory parallel programming in

      C/C++ and Fortran". See:

        http://gcc.gnu.org/onlinedocs/libgomp/

      The default is 'N'. Say 'Y' if you need it, and report success/failure.

config CC_GCC_LIBSSP

    bool

    prompt "Compile libssp"

    default n

    help

      libssp is the run-time Stack-Smashing Protection library.

      The default is 'N'. Say 'Y' if you need it, and report success/failure.

#-----------------------------------------------------------------------------

comment "Misc. obscure options."

config CC_CXA_ATEXIT

    bool

    prompt "Use __cxa_atexit"

    default y

    depends on ! BARE_METAL

    help

      If you get the missing symbol "__cxa_atexit" when building C++ programs,

      you might want to try disabling this option.

config CC_GCC_DISABLE_PCH

    bool

    prompt "Do not build PCH"

    default n

    help

      Say 'y' here to not use Pre-Compiled Headers in the resulting toolchain.

      at the expense of speed when compiling C++ code.

      For some configurations (most notably canadian?), PCH are broken, and

      need to be disabled. Please see:

        http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

config CC_GCC_SJLJ_EXCEPTIONS

    tristate

    prompt "Use sjlj for exceptions"

    depends on ! BARE_METAL

    default m

    help

      'sjlj' is short for setjmp/longjmp.

      On some architectures, stack unwinding during exception handling

      works perfectly well without using sjlj, while on some others,

      use of sjlj is required for proper stack unwinding.

       Option  | sjlj use           | Associated ./configure switch

      ---------+--------------------+--------------------------------

         Y     | forcibly used      | --enable-sjlj-exceptions

         M     | auto               | (none, ./configure decides)

         N     | forcibly not used  | --disable-sjlj-exceptions

      It should be safe to say 'M' or 'N'.

      It can happen that ./configure is wrong in some cases. Known

      case is for ARM big endian, where you should say 'N'.

config CC_GCC_LDBL_128

    tristate

    prompt "Enable 128-bit long doubles"

    default m

    depends on CC_GCC_4_2_or_later

    help

      Saying 'Y' will force gcc to use 128-bit wide long doubles

      Saying 'N' will force gcc to use 64-bit wide long doubles

      Saying 'M' will let gcc choose (default is 128-bit for

                 glibc >= 2.4, 64-bit otherwise)

      If in doubt, keep the default, ie. 'M'.