search for: ac_lang

On Mon, 29 Jun 2020 at 11:24, I?aki Ucar <iucar at fedoraproject.org> wrote: > > On Mon, 29 Jun 2020 at 10:21, Roger Bivand <Roger.Bivand at nhh.no> wrote: > > > > In the rgdal package, configure.ac has had : ${LDFLAGS=`"${RBIN}" CMD > > config LDFLAGS`} at least since 2012, so picking up LDFLAGS known to the R > > version installed. Very

...ouldn?t these be CXX1XSTD and CXX1XFLAGS respectfully? (on the second and fourth line) CXX1X=`"${R_HOME}/bin/R" CMD config CXX11X` CXX1XSTD=`"${R_HOME}/bin/R" CMD config CXX11XSTD` CXX="$(CXX1X) $(CXX1XSTD)" CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXX11XFLAGS` AC_LANG(C++) Sorry if this has been reported before, Jonathan Lisic

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....

...lt;tr1/unordered_map> if not, or <map> if all else fails. I (think I) can accomplish this with configure.ac as AC_INIT("DESCRIPTION") CXX=`"${R_HOME}/bin/R" CMD config CXX` CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS` AC_CONFIG_HEADERS([src/config.h]) AC_LANG(C++) AC_CHECK_HEADERS([unordered_map tr1/unordered_map]) AC_OUTPUT Use of configure.ac does not seem to be entirely consistent with section 1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see below) code one should CXX_STD = CXX11 in Makevars(.win). My code does no...

Hello, I've written a package that may use OpenMP to speed up computations. OpenMP is supported in recent Gcc versions by using the -fopenmp flag. The problem is that flag crashed gcc versions that do not support OpenMP. So what is the best way for a package to handle this issue. Has someone a configure script that deals with this ? Thanks, Karl [[alternative HTML version deleted]]

I hacked zstd support into OpenSSH a while ago and just started to clean it up in the recent days. The cleanup includes configuration support among other things that I did not have. During testing I noticed the following differences compared to zlib: - highly interactive shell output (as in refreshed at a _very_ high rate) may result in higher bandwidth compared to zlib. Since zstd is quicker

I added ZSTD support to OpenSSH roughly over a year and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port