I'm trying to port buildsystem of my project to GNU autotools. The code need to be compiled with -std=c++11 or -std=c++0x flag. I want my configure script to check if compiler supports C++11 or not. I tried adding AX_CHECK_COMPILE_FLAG([-std=c++0x], [CXXFLAGS="$CXXFLAGS -std=c++0x"]) to configure.ac file but configure fails with this error:
...
./configure: line 2732: syntax error near unexpected token `-std=c++0x,'
./configure: line 2732: `AX_CHECK_COMPILE_FLAG(-std=c++0x, CXXFLAGS="$CXXFLAGS -std=c++0x")'
Hopefully there will be more comprehensive support for C++11 in future autoconf releases. In the mean time, I use a C++11 source test from ax_cxx_compile_stdcxx_11.m4 in the GNU autoconf archive:
AC_PROG_CXX
AC_LANG_PUSH([C++])
AC_COMPILE_IFELSE([AC_LANG_SOURCE(
[[template <typename T>
struct check
{
static_assert(sizeof(int) <= sizeof(T), "not big enough");
};
typedef check<check<bool>> right_angle_brackets;
int a;
decltype(a) b;
typedef check<int> check_type;
check_type c;
check_type&& cr = static_cast<check_type&&>(c);]])],,
AC_MSG_FAILURE(['$CXX $CXXFLAGS' does not accept ISO C++11]))
The error you're getting seems to come from AX_CHECK_COMPILE_FLAG not being expanded in your configure script. You can verify whether it is expanded by grepping AX_CHECK_COMPILE_FLAG in configure. If the grep finds it there, then it is not expanded.
You can also check it by looking into file aclocal.m4, where aclocal should copy it's definition.
The definition of this macro is not included in basic autoconf package, but in the autoconf archives. So you're probably missing this package. (Exact name of the package may differ between distributions, it is sys-devel/autoconf-archive in Gentoo and it seems to be autoconf-archive in Debian and Ubuntu).
Related
I am using coverity to analyze my code.
but when I configured cov, got an error.
> cov-configure --config
> /home/opt/coverity/Coverity/cov-admin/cov-conf/config/coverity_config_armcc.xml
> --comptype clang --compiler ****** --template
got an error:
Unknown compiler type clang
The only supported compiler types are:
******
So I'm doubt that if coverity supports clang compiler, or I have done something wrong.
The coverity version is 8.
BRs.
Coverity 8 definitely supports Clang. The issue is you're using --comptype clang - the comptype for Clang is --comptype clangcc (note the extra cc).
If you're in doubt, cov-configure --list-compiler-types is a good place to start, as is the documentation.
Note that so long as your Clang binary has the default name, cov-configure --clang should be all you need. Otherwise I strongly recommend you use --template on your cov-configure command line as well, as the CIT implementation for Clang makes heavy usage of "required" arguments and you're unlikely to get a successful capture of your build without using --template.
After updating to Command Line Tools 6.3 from the App Store, programs including <vector> or <iterator> which internally include <__debug> will cause file not found error as follows. The cpp is nothing interesting but includes in one of the included headers.
c++ -O3 -I/Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers -L/Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/build/binaries/clusterStaticLibrary /Users/farleylai/Documents/dev/git/ESMS/Optimizer/build/StreamIt/FIR/511/512/combined_threads.cpp -o streamit -lcluster -lpthread -lstdc++
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/build/StreamIt/FIR/511/512/combined_threads.cpp:9:
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/node_server.h:22:
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/thread_info.h:20:
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/connection_info.h:19:
/Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/socket_holder.h:43:25: warning: delete called on 'mysocket' that is abstract but has non-virtual destructor
[-Wdelete-non-virtual-dtor]
if (!is_mem_socket) delete sock;
^
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/build/StreamIt/FIR/511/512/combined_threads.cpp:9:
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/node_server.h:22:
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/thread_info.h:26:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/vector:265:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__bit_reference:15:
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/algorithm:641:10: fatal error: '__debug' file not found
#include <__debug>
^
Any ideas to fix this?
I don't expect to specify any additional C++ flags.
Thanks.
PS: MacBook pro on OSX 10.10.3
Updates:
The issue is verified by Apple on their developer's forum. In Command Line Tools 6.2, the inclusion of __debug is conditionally guarded as follows but not in 6.3.
#ifdef _LIBCPP_DEBUG
# include <__debug>
#else
# define _LIBCPP_ASSERT(x, m) ((void)0)
#endif
And libcxx people talked about removing the guards of __debug here. It feels like __debug never exists on OSX.
Downgrade the Command Line Tools to 6.2 via Apple's Developer Download Page.
Be careful to download the correct version for your OS X:
OS X 10.10 commandlinetoolsosx10.10forxcode6.2.dmg
OS X 10.9 commandlinetoolsosx10.9forxcode6.2.dmg
This works because the inclusion of __debug is conditionally guarded as follows in Command Line Tools 6.2 but not in 6.3.
#ifdef _LIBCPP_DEBUG
# include <__debug>
#else
# define _LIBCPP_ASSERT(x, m) ((void)0)
#endif
In my opinion this is the safest way, because:
You don't compromise your toolchain
You can easily upgrade via the App Store when Apple fixes the issue
If you add a file manually you have to delete it later or more problems could occur
Update - 21.04.2015
Problem fixed by Apple.
After installing Command Line Tools 6.3.1 everything works as expected!
Temporarily create the missing __debug file where _LIBCPP_ASSERT is defined as in Command Line Tools 6.2 for OS X.
echo '#define _LIBCPP_ASSERT(x, m) ((void)0)' | sudo tee -a /Library/Developer/CommandLineTools/usr/include/c++/v1/__debug > /dev/null
Remove the temporary file after the build finished.
sudo rm /Library/Developer/CommandLineTools/usr/include/c++/v1/__debug
Warning!!! This is a hack, use at your own risk!!! This work-around is only meant as a temporary fix until Apple provides an update to the command-line tools.
OK, here we go: Create the file yourself and put the following content into it:
#ifndef _LIBCPP_ASSERT
#define _LIBCPP_ASSERT(...) ((void)0)
#endif
This seems to work for me, but it is certainly not the right thing to do. Make sure the file is located at the right place /Library/Developer/CommandLineTools/usr/include/c++/v1/__debug with the right owner/permissions.
This is now fixed in Command Line Tools 6.3.1, available from https://developer.apple.com/downloads. The update should appear automatically in your App Store Updates (though it’s labelled as 6.3, not 6.3.1). Apologies for the inconvenience, and thanks very much for reporting the issue.
Earlier: A workaround which worked for me in a simple case was setting a minimum of OS X 10.8 or earlier, with “-mmacosx-version-min=10.8”.
I followed #Flash Sheridan advice and got my CLT working again (git, ruby, brew...) - I used "Command Line Tools (OS X 10.10) for Xcode 6.3.1".
I have written and built an R package that depends on Rcpp and requires the C++0x standard (for using the tgamma function in C++). I have tested the package on various desktop computers and operating systems, and it always seems to install and work fine. However, I would also like to use the package on an HPC server. When I try to install the package there in my local R library tree using R CMD INSTALL test (where test is the name of the package), I get the following error message from the compiler:
/usr/include/c++/4.4.7/c++0x_warning.h(31): catastrophic error: #error directive: This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
#error This file requires compiler and library support for the upcoming \
^
compilation aborted for Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.cpp (code 4)
make: *** [Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.o] Error 4
ERROR: compilation failed for package ‘test’
It basically tells me that I should enable C++0x support when the compiler is called (as in this post). Yet, I thought adding the statement CXX_STD = CXX11 to the src/Makevars file in the R package would actually tell the compiler that this version needs to be used. And indeed that seems to be the case on various desktop computers I have tried. So my question is: how can I tell the compiler on the server that this C++ version should be used for compilation? Alternatively, how else can I install the package?
On the server, I load the module for R by entering module load math/R on the terminal before trying to install the package, and it reports back that the following modules were loaded:
Loading module dependency 'compiler/intel/13.1'.
Loading module dependency 'numlib/mkl/11.0.5'.
Edit 1: The server is a German university cluster called bwUniCluster. It is based on KITE 2.0/RHEL6.5/Lustre 2.5.2. As far as I can tell from the module message reported above, it seems to be the Intel C++ Compiler XE (ICPC) version 13.1.3. But actually I have no clue about compilers, so if you need to know anything more specific, please let me know.
Edit 2 It's also possible to execute module load compiler/gnu/4.9 on the terminal before I try to install the package. This results in the following error message (similar as the one above), which leads me to think that this is not a version problem:
/pfs/data1/software_uc1/bwhpc/common/compiler/gnu/4.9.2/bin/../include/c++/4.9.2/bits/c++0x_warning.h(32): catastrophic error: #error directive: This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
compilation aborted for Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.cpp (code 4)
make: *** [Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.o] Error 4
ERROR: compilation failed for package ‘test’
Edit 3: One of the comments suggests that both the R package and R itself need to be compiled using the same compiler version. Is this correct? R was built using g++ 4.4.7 on this machine. Does this mean that the only feasible solution is to convince the sys admin to recompile R with the other 4.9.2 compiler and provide it as a new module? I find this hard to believe, given the following sentence in the "Writing R Extensions" manual:
On these platforms, it is necessary to select a different compiler for C++11, via personal or site Makevars files.
The solution was indeed to recompile R on the server with a newer compiler, in this case Intel 14 (as discussed in Edit 3 in the original post). The sys admin was so kind to set up a new module for this R version.
I have just downloaded clang 3.3 (homebrew) from the LLVM web page to my mac (OS X 10.8.4), but get this compiler error when using std=c++11 stdlib=libc++:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:594:
In file included from /usr/include/c++/v1/memory:590:
In file included from /usr/include/c++/v1/typeinfo:61:
/usr/include/c++/v1/exception:146:5: error: an attribute list cannot appear here
_LIBCPP_NORETURN friend void rethrow_exception(exception_ptr);
^~~~~~~~~~~~~~~~
/usr/include/c++/v1/__config:190:28: note: expanded from macro '_LIBCPP_NORETURN'
# define _LIBCPP_NORETURN [[noreturn]]
^~~~~~~~~~~~
It seems that I also need another libc++ (even though it was said that it was 100% complete on MAC ...), but I cannot find any. Any help appreciated. Just for your info:
> clang++ -v
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
And, yes, I googled it and found this: http://comments.gmane.org/gmane.comp.compilers.llvm.bugs/24138 claiming it's resolved in libc++ trunk ???
Okay, as suggested by Howard, I've downloaded tip-of-the-trunk libc++ into /opt/local/share/libcxx, but have trouble building it. The manual says to cd libcxx/lib, export TRIPLE=-apple-, and run ./buildit. I presume this implies bash (I'm usually a tcsh user, so I moved my .tcshrc, got a new shell and started bash). I did that and the compilations worked, but the library build failed. Apparently ./buildit doesn't see $TRIPLE=-apple-, as it picks the wrong LDSHARED_FLAG (not that on line 81, but that on line 103, which is to be used if $TRIPLE is not set), even though echo $TRIPLE yields -apple- as it should. When I add the statement echo TRIPLE = $TRIPLE at the top of buildit, it reports nothing. How come? What is wrong here?
The failure was that because the wrong LDSHARED_FLAG was picked the loading didn't work (ld complaint about the unknown option -soname which, I think, makes sense under linux). I don't know why buildit (a #! /bin/sh file) didn't pick up the TRIPLE environment variable (it did pick up several unwanted ones such as CXX and CC). I now simply added TRIPLE=-apple- at the top of that file and it did built the library. However, the loader spitted out several warnings all of which were of the form
ld: warning: direct access in ___cxa_bad_typeid to global weak symbol typeinfo for std::bad_typeid means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
But most importantly, it works (the compilation at least, I have yet to test the library). I have one final question. The advice was to use -I and -L to tell the compiler about the whereabouts of this version. Is it not possible to put it into the usual place /usr/include/c++/v1/? Note that Xcode has its version somewhere else anyway and I had put in a symbolic link (/usr/include/c++/v1/) to that one to get my homebrew clang 3.2 working (after the some Xcode update). What about the library? Can I also put it in a standard place?
Here is the home page of libc++:
http://libcxx.llvm.org
You can download the tip-of-trunk libc++ from there. You can tell clang to point to your download with -nostdinc++ -I<path-to-libc++>/include. You can also tell clang to link to your tip-of-trunk libc++ with -L<path-to-libc++>/lib and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib. The directions are all on the libc++ home page.
Xcode is the easiest way to get clang + libc++. But if you want the very latest, this is the place to go.
Congratulations!
Don't worry about the ld warning. It is a harmless ld bug that will be fixed in a future release. I see it on 10.8.4 too and it doesn't hurt anything.
The libc++ headers no longer live at /usr/include/c++/v1. Xcode has migrated them into itself. Having libc++ headers at /usr/include/c++/v1 from older installs has been a source of confusion and bugs. I regularly use -nostdinc++ -I to point to the libc++ headers I want (I often have several versions going at the same time), and that works well for me.
It is possible for you to replace your /usr/lib/libc++.1.dylib with that you have built. I do not recommend doing this. I have to sometimes to do a proper test, but I always do so very carefully because sometimes this causes me to have to reboot onto a backup disk and restore my /usr/lib to its original state. If you do go this route, it is a very good idea to have a backup of the original /usr/lib/libc++.1.dylib very handy.
I recommend instead -L on the command line, and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib in the shell. More than one person (including myself) has gotten their computer into a really nasty place by not following this advice.
If you run testit (under test/), all you need is DYLD_LIBRARY_PATH in that shell. The testit script is set up to point to the right places without an install.
Also I recommend figuring out why you had to modify buildit. No one else is seeing that behavior. printenv on your command line may help in this endeavor.
libc++ is updated often. We try to keep tip-of-trunk always in a shippable state.
When using gcc version 4.3.2, I see how to generate specs using:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
Now changing to the same directory as libgcc:
cd /usr/local/gcc-4.3.2/lib/gcc/x86_64-unknown-linux-gnu/4.3.2
/usr/local/gcc-4.3.2/bin/gcc -dumpspecs > specs
I have a populated specs file that I can modify. However, once that is done I still see that:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
How do I tell gcc to use that specs file by default rather than forcing me to pass a -specs parameter every compile? I would like it to match another system I have where I get the following:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Reading specs from /usr/local/gcc-4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/specs</code>
As you can see, the major difference between the two systems is that the existing setup is 32-bit and I am now trying to match that on a 64-bit system. The version of Linux is otherwise the same and I am compiling the same version of gcc. (With both systems gcc 4.3.2 is the second gcc installation, with 4.1.2 being used to compile 4.3.2)
As hinted at by the strace suggestion by Johannes Schaub - litb, it was a problem with where the compiler was looking for the file. As it turns out, the non-working installation had an environment variable set in the .bashrc that was causing the confusion.
The correct location for the specs file is indeed the same directory that libgcc is in. Just be sure you're looking there.
I used this command line:
/usr/bin/set-gcc-default-3.sh i686-pc-mingw32
but you'll probably want:
/usr/bin/set-gcc-default-4.sh i686-pc-linux-gnu
(Note the -4 instead of -3)
This is built using the "alternatives" stuff, please see
/usr/sbin/alternatives.exe --help
And also see pages such as http://linux.about.com/library/cmd/blcmdl8_alternatives.htm
You rebuild gcc with your specs file as part of the build!
A simpler solution is to create an alias:
alias gcc_Gary gcc -specs /<folder With Specs File>/newSpecsFile