I would like to include a different file depending on the version of GCC. More precisely I want to write:
#if GCC_VERSION >= 4.2
# include <unordered_map>
# define EXT std
#elif GCC_VERSION >= 4
# include <tr1/unordered_map>
# define EXT std
#else
# include <ext/hash_map>
# define unordered_map __gnu_cxx::hash_map
# define EXT __gnu_cxx
#endif
I don't care about gcc before 3.2.
I am pretty sure there is a variable defined at preprocessing time for that, I just can't find it again.
There are a number of macros that should be defined for your needs:
__GNUC__ // major
__GNUC_MINOR__ // minor
__GNUC_PATCHLEVEL__ // patch
The version format is major.minor.patch, e.g. 4.0.2
The documentation for these can be found here.
Ok, after more searches, it one possible way of doing it is using __GNUC_PREREQ defined in features.h.
#ifdef __GNUC__
# include <features.h>
# if __GNUC_PREREQ(4,0)
// If gcc_version >= 4.0
# elif __GNUC_PREREQ(3,2)
// If gcc_version >= 3.2
# else
// Else
# endif
#else
// If not gcc
#endif
As a side note:
To find all the predefined macros:
Create empty file t.cpp
g++ -E -dM t.cpp
Related
The point of this effort is to prevent me from dual booting windows ,having to install CPLEX twice in the same system (storage is quite limited) and ofc be able to compile the required cross-platform executables from my main os which is debian linux.
For this reason i'm using mingw64 and my compilation script looks like this:
#!/bin/sh
#COMPILATION FLAGS
FLAGS='-DIL_STD -DILOUSEMT -D_REENTRANT'
EXTRA='-std=c++11 -static -static-libgcc -static-libstdc++'
#INCLUDES
OPL_INCL='-I/opt/ibm/ILOG/CPLEX_Studio128/opl/include'
CPL_INCL='-I/opt/ibm/ILOG/CPLEX_Studio128/cplex/include'
CON_INCL='-I/opt/ibm/ILOG/CPLEX_Studio128/concert/include'
#LINKER
OPL_LIB='-L/opt/ibm/ILOG/CPLEX_Studio128/opl/lib/x64_windows_vs2017/stat_mda'
CPL_LIB='-L/opt/ibm/ILOG/CPLEX_Studio128/cplex/lib/x64_windows_vs2017/stat_mda'
CON_LIB='-L/opt/ibm/ILOG/CPLEX_Studio128/concert/lib/x64_windows_vs2017/stat_mda'
#echo $FLAGS
/usr/bin/x86_64-w64-mingw32-g++ $FLAGS $OPL_INCL $EXTRA main.cpp $OPL_LIB $CON_LIB $CPL_LIB -lcplex -lm -lpthread
#g++ -std=c++11 $FLAGS $OPL_INCL main.cpp $OPL_LIB $CON_LIB $CPL_LIB -lcplex -lm -lpthread
What I have done is that I copied the windows version of the library files from another windows installation, and I'm now trying to compile my code using the global (I suppose) include files but using the windows version (.lib) of the necessary cplex libraries.
I thought that the nightmare would be the linking, but to my surprise, I didn't even manage to get there. The Mingw compiler is aborting compilation because of a generic.h file missing (which from what I understand with a bit of searching, it should be related with the kernel or something)
In file included from /opt/ibm/ILOG/CPLEX_Studio128/opl/include/ilconcert/iloenv.h:21:0,
from /opt/ibm/ILOG/CPLEX_Studio128/opl/include/ilconcert/iloalg.h:21,
from /opt/ibm/ILOG/CPLEX_Studio128/opl/include/ilconcert/ilomodel.h:21,
from /opt/ibm/ILOG/CPLEX_Studio128/opl/include/ilcplex/ilocplex.h:27,
from /opt/ibm/ILOG/CPLEX_Studio128/opl/include/ilopl/iloopl.h:23,
from main.cpp:3:
/opt/ibm/ILOG/CPLEX_Studio128/opl/include/ilconcert/ilosys.h:262:21: fatal error: generic.h: No such file or directory
#include "generic.h"
^
compilation terminated.
I also tried just for testing to compile using g++ and this error was quickly bypassed and as expected the new errors are related with linking the cplex library : /usr/bin/ld: cannot find -lcplex, which is probably missing cause I have not included the linux library folders.
Do I have any hopes to do that or is this impossible in the first place?
PS: I have a much simpler piece of code where I'm doing exactly the same thing (no CPLEX) involved and compilation works like a charm. So I suppose that the issue should be also CPLEX related.
The short answer is no; you probably don't have any hope of getting this to work.
In ilosys.h at line 262, we see the following:
#if !(defined(name2))
# if defined(ILO_MSVC) || defined(ILO_LINUX) || defined(ILO_APPLE) || defined(ILO_HP11)
# undef name2
# define name2(a,b) _name2_aux(a,b)
# define _name2_aux(a,b) a##b
# else
#include "generic.h"
# endif
#endif
The suspicious part is that ILO_MSVC is not defined and this is why generic.h is being included. If we go to ilosys.h at line 11, we see:
#if defined(_MSC_VER)
# undef _Windows
# define _Windows
# undef _WINDOWS
# define _WINDOWS
# undef ILO_WINDOWS
# define ILO_WINDOWS
# undef ILO_MSVC
# define ILO_MSVC
#include <stddef.h>
# if defined(_WIN64)
# undef ILO64
# define ILO64
# undef ILO_WIN64
# define ILO_WIN64
# else
# undef ILO_WIN32
# define ILO_WIN32
# endif
//# if defined(ILO_MSVC8)
//# undef _WIN32_WINNT
//# define _WIN32_WINNT 0x0400
//# endif
#endif
So, ILO_MSVC is only defined if _MSC_VER is defined. And, _MSC_VER is only defined if you have a Microsoft Visual C++ compiler installed (e.g., see here).
Finally, if you look at the detailed system requirements for CPLEX and Windows, it's pretty clear that Microsoft Visual Studio 2015 or 2017 is required.
I just started with C++ and i think the best way is to look at source codes. I have code as follows in the header file.
#ifdef _MSC_VER
#define MYAPP_CACHE_ALIGNED_RETURN /* not supported */
#else
#define MYAPP_CACHE_ALIGNED_RETURN __attribute__((assume_aligned(64)))
#endif
I am using gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11) and its quite old. I get this warning during compilation:
warning: 'assume_aligned' attribute directiv e ignored [-Wattributes] –
How can I make the if statement more specific to fix the the warning during compilation?
It seems that assume_aligned is not supported in RHEL's GCC (it hasn't been backported to upstream gcc-4_8-branch and also not available in Ubuntu 14.04's GCC 4.8.4 so that wouldn't be surprising).
To emit a more user-friendly diagnostics you can do an explicit check for GCC version in one of your headers:
#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 9)
# warning "Your version of GCC does not support 'assume_aligned' attribute"
#endif
But this may not work if your distro vendor has back-ported assume_aligned from upstream (which is not the case for RedHat and Ubuntu but who knows about other distros). The most robust way to check this would be to do a build-time test in configure script or in Makefile:
CFLAGS += $(shell echo 'void* my_alloc1() __attribute__((assume_aligned(16)));' | gcc -x c - -c -o /dev/null -Werror && echo -DHAS_ASSUME_ALIGNED)
This will add HAS_ASSUME_ALIGNED to predefined macro if the attribute is supported by compiler.
Note that you can achieve similar effect with __builtin_assume_aligned function:
void foo() {
double *p = func_that_misses_assume_align();
p = __builtin_assume_aligned(p, 128);
...
}
I think this is part of the problem at No type named 'unique_ptr' in namespace 'std' when compiling under LLVM/Clang. According to Marshall Clow, I can detect -stdlib=libc++ via _LIBCPP_VERSION:
If you're writing cross-platform code, sometimes you need to know what
standard library you are using. In theory, they should all offer
equivalent functionality, but that's just theory. Sometimes you just
need to know. The best way to check for libc++ is to look for the
preprocessor symbol _LIBCPP_VERSION. If that's defined, then you're
using libc++.
#ifdef _LIBCPP_VERSION
// libc++ specific code here
#else
// generic code here
#endif
Unfortunately, that breaks down with Apple's Clang (3.4-SVN) and the Clang (3.6) I built from sources after downloading from the LLVM project. I'm guessing the test is only valid under Xcode.
How can I reliably detect -stdlib=libc++ in the preprocessor?
Here is the test case:
$ cat test-clapple.cxx
// Need to test {C++03,C++11} x {libc++, no libc++}
// c++ -c test-clapple.cxx
// - OK
// c++ -stdlib=libc++ -c test-clapple.cxx
// - OK
// c++ -std=c++11 -c test-clapple.cxx
// - FAILS, no type named 'unique_ptr' in namespace 'std'
// c++ -std=c++11 -stdlib=libc++ -c test-clapple.cxx
// - OK
#include <ciso646>
#if (__cplusplus >= 201103L) || (_MSC_VER >= 1600)
# pragma message "C++11"
#elif (__cplusplus >= 199711L)
# pragma message "C++03"
#endif
#if (_LIBCPP_VERSION)
# pragma message "libc++"
#else
# pragma message "no libc++"
#endif
#if defined(__apple_build_version__)
# pragma message "Apple build"
#else
# pragma message "non-Apple build"
#endif
#if (__cplusplus >= 201103L) || (_MSC_VER >= 1600) // C++11
# include <memory>
#else
# include <tr1/memory>
#endif
// Manage auto_ptr warnings and deprecation in C++11
#if (__cplusplus >= 201103L) || (_MSC_VER >= 1600)
template<typename T>
using auto_ptr = std::unique_ptr<T>;
#else
using std::auto_ptr;
#endif // C++11
int main(int argc, char* argv[])
{
return argc;
}
This project does not use Autotools, Cmake, Boost, or other external libraries or frameworks.
The only effect -stdlib=libc++ has on the preprocessor is to change the include paths it uses to find standard library headers, so you can't detect the presence of -stdlib=libc++ on the command-line per se, you can only detect which standard library headers get included. Obviously you can't detect that without actually including one or more standard library headers.
If you include any libc++ header then _LIBCPP_VERSION will be defined, so the way to detect -stdlib=libc++ is to include at least one C++ library header and check for _LIBCPP_VERSION.
In C++20 and later, it is recommend to #include <version>, which was created specifically for this purpose. Prior to C++20, it is recommended to #include <ciso646> which serves no purpose in C++ and declares nothing, but for libc++ does define the _LIBCPP_VERSION macro. However, for libstdc++ historically <ciso646> did not define any macros such as __GLIBCXX__ that can be used to detect libstdc++. That changed with GCC 6.1 so <ciso646> can be used now, but for older releases you need to include a different header to detect libstdc++.
The directive:
#ifndef __cplusplus
#error C++ is required
#elif __cplusplus < 201402L
#error C++14 is required
#endif
The command-line: g++ -Wall -Wextra -std=c++14 -c -o header.o header.hpp
My g++ version: g++ (tdm-1) 4.9.2
The error C++14 is required is generated even when I added -std=c++14, I don't know why.
Please tell me how to fix this.
According to the GCC CPP manual (version 4.9.2 and 5.1.0):
__cplusplus This macro is defined when the C++ compiler is in use. You can use __cplusplus to test whether a header is compiled by a C compiler or a C++ compiler. This macro is similar to __STDC_VERSION__, in that it expands to a version number. Depending on the language standard selected, the value of the macro is 199711L, as mandated by the 1998 C++ standard; 201103L, per the 2011 C++ standard; an unspecified value strictly larger than 201103L for the experimental languages enabled by -std=c++1y and -std=gnu++1y.
You can check that g++ --std=c++14 defines __cplusplus as:
Version __cplusplus
4.8.3 201300L
4.9.2 201300L
5.1.0 201402L
For clang++ --std=c++14:
Version __cplusplus
3.3 201305L
3.4 201305L
3.5.x 201402L
3.6 201402L
3.7 201402L
So a safer check should probably be:
#ifndef __cplusplus
# error C++ is required
#elif __cplusplus <= 201103L
# error C++14 is required
#endif
As specified in the comment, this could mean partial C++14 support.
To check for a specific feature you could also try Boost Config (especially Macros that describe C++14 features not supported).
I'm using autotools as build system for a library of mine. Recently library is ported to Windows. Library compiles and links successfully though I encountered a strange error. There is only static libraries after configure and make. Evertything looks OK except a warning from libtool:
libtool: undefined symbols not allowed in i686-pc-mingw32 shared
I have exported all symbols for Windows machines by this code:
#ifdef _WIN32
# ifdef DLL_EXPORT
# define LIBRARY_API __declspec(dllexport)
# else
# define LIBRARY_API __declspec(dllimport)
# endif
#endif
#ifndef _WIN32
# define LIBRARY_API
#endif
And in every single definition I have:
class LIBRARY_API myClass {
// ...
Notes:
Operating System: Windows 8 x86_64
Compiler suite: MinGW x86_64, MSYS x86
In your configure.ac, make sure your libtool initialization looks like:
LT_INIT([win32-dll])
Also, you need to pass -no-undefined flag to libtool in your Makefile.am. This flag disables the warning you are getting:
libexample_la_LDFLAGS = -no-undefined
More details about this in the LT_INIT documentation.