search for: ac_lang_push

...isibility=hidden if using a gcc that supports it > - save_CXXFLAGS="$CXXFLAGS" > - AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden]) > - VISIBILITY_CXXFLAGS="-fvisibility=hidden" > - CXXFLAGS="$CXXFLAGS $VISIBILITY_CXXFLAGS" > - AC_LANG_PUSH([C++]) > - AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]), > - [VISIBILITY_CXXFLAGS="" ; AC_MSG_RESULT([no])]); > - AC_LANG_POP([C++]) > - > - # Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed. > - CXXFLAGS=$save_...

...isibility=hidden if using a gcc that supports it > - save_CXXFLAGS="$CXXFLAGS" > - AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden]) > - VISIBILITY_CXXFLAGS="-fvisibility=hidden" > - CXXFLAGS="$CXXFLAGS $VISIBILITY_CXXFLAGS" > - AC_LANG_PUSH([C++]) > - AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]), > - [VISIBILITY_CXXFLAGS="" ; AC_MSG_RESULT([no])]); > - AC_LANG_POP([C++]) > - > - # Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed. > - CXXFLAGS=$save_CXXFLAGS >...

...e change to configure.ac (indented two spaces just for email) edd at max:~/svn/r-devel$ svn di configure.ac Index: configure.ac =================================================================== --- configure.ac (revision 64031) +++ configure.ac (working copy) @@ -906,6 +906,7 @@ AC_LANG_PUSH(C++) AC_OPENMP +AX_CXX_COMPILE_STDCXX_11(noext) AC_LANG_POP(C++) ### *** ObjC compiler edd at max:~/svn/r-devel$ After running 'aclocal -Im4; autoheader; autoconf', the configure test then properly detected C++11 (or, in one case, C++0x) on four different compilers: [ g+...

Patch 1 adds a check for the compilers visibility macro to configure.ac. Patch 2 avoids redefined symbol errors in clang of the tls entry points. Based on a suggestion from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> in http://llvm.org/bugs/show_bug.cgi?id=19778. Tested with gcc 4.9 and clang 3.6(rc) Marc Dietrich (2): configure: add visibility macro detection to configure

...ELSE([ - AC_LANG_SOURCE( - [[ - int main() { - #ifndef _FORTIFY_SOURCE - return 0; - #else - this_is_an_error; - #endif - } - ]] - )], [ - AC_MSG_RESULT([yes]) - XIPH_ADD_CFLAGS([-D_FORTIFY_SOURCE=2]) - ], [ - AC_MSG_RESULT([no]) - ]) + AX_ADD_FORTIFY_SOURCE AC_LANG_PUSH([C++]) XIPH_ADD_CXXFLAGS([-Weffc++]) diff --git a/m4/ax_add_fortify_source.m4 b/m4/ax_add_fortify_source.m4 new file mode 100644 index 00000000..d443814b --- /dev/null +++ b/m4/ax_add_fortify_source.m4 @@ -0,0 +1,53 @@ +# ===========================================================================...

Hi, I discovered a little error in vorbis.m4. The source for the test compile uses vorbis_encode_init() but does not include vorbisenc.h. This causes the test to fail when AC_LANG(C++) is used in my configure.ac script. For now my work-around is to surround the Ogg Vorbis tests with AC_LANG_PUSH(C) ... AC_LANG_POP(C) calls, but it should probably be fixed. Thanks, Davy --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word...

Hi Erik, similar to what I did for libsndfile, this is to simplify the handling of adding -D_FORTIFY_SOURCE=2. Regards David

..._LIB(lzma, lzma_version_number, [have_lzma=yes], [have_lzma=no]) + if test "${have_lzma}" = yes; then + AC_CHECK_HEADERS(lzma.h, [have_lzma=yes], [have_lzma=no]) + fi if test "x${have_lzma}" = xyes; then AC_CACHE_CHECK([if lzma version >= 5.0.3], [r_cv_have_lzma], [AC_LANG_PUSH(C) @@ -3223,11 +3300,9 @@ if test "x${have_lzma}" = xyes; then AC_DEFINE(HAVE_LZMA, 1, [Define if your system has lzma >= 5.0.3.]) LIBS="-llzma ${LIBS}" - fi else - have_lzma="no" + AC_MSG_ERROR("liblzma library and headers are required&quot...

On 2015-11-04 17:31, aixtools wrote: > On 2015-11-04 16:51, aixtools wrote: >> On 2015-10-15 15:02, Prof Brian Ripley wrote: >>> On 15/10/2015 13:32, Michael Felt wrote: >>>> Hi. >>>> >>>> Just wanted to let you know I am getting close to packaging R for >>>> AIX in >>>> 64.bit mode. >>> >>> Which

This patch series modernizes various aspects of the autotools based build system. There is a lot more that could and should be done, but I tried to stay conservative for now and just resolve some of the most obvious issues. Max Horn (5): configure: replace XIPH_C_FIND_ENDIAN by AC_C_BIGENDIAN autogen.sh: replace this by a simple call to autoreconf configure: always print

...to CFLAGS]) + AC_LINK_IFELSE([ + AC_LANG_SOURCE( + [[ + int main() { + #ifndef _FORTIFY_SOURCE + return 0; + #else + this_is_an_error; + #endif + } + ]] + )], [ + AC_MSG_RESULT([yes]) + XIPH_ADD_CFLAGS([-D_FORTIFY_SOURCE=2]) + ], [ + AC_MSG_RESULT([no]) + ]) AC_LANG_PUSH([C++]) XIPH_ADD_CXXFLAGS([-Weffc++]) diff --git a/include/FLAC/assert.h b/include/FLAC/assert.h index b546fd07..55b34777 100644 --- a/include/FLAC/assert.h +++ b/include/FLAC/assert.h @@ -34,7 +34,7 @@ #define FLAC__ASSERT_H /* we need this since some compilers (like MSVC) leave assert()s on...

Hi Erik, I've found a middleground for the problem of setting default CFLAGS. I've gone back to setting them if {C,CXX,CPP,LD}FLAGS are unset at the onset of the configure script (i.e., the user hasn't specified anything) and then proceed to set them to the defaults as before. This has been suggested before: https://lists.gnu.org/archive/html/autoconf/2006-04/msg00022.html In