I am trying to compile the boost log library and I keep getting this error from the dump_avx2.cpp file
error: always_inline function '_mm256_set1_epi32' requires target feature 'sse4.2', but would be inlined into function 'dump_data_avx2' that is compiled without support for 'sse4.2'
boost/boost/libs/log/src/dump_avx2.cpp:71:31: note: expanded from macro 'BOOST_LOG_AUX_MM_CONSTANTS'
const __m256i mm_char_0 = _mm256_set1_epi32(0x30303030);\
^
I get a lot of errors that are very similar to the one above, all of them have the same error message but different locations in the file where they occur, for reference I am on the commit hash 68701167a1020b0b4c47b76e31d3a3da9e2faf3f for the Boost.Log submodule as fetched from the github repo (https://github.com/boostorg/boost)
Does anyone know how I can go about resolving this issue? I am building with a C++14 compiler and this is what I get when I type g++ --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Thanks!
Note I should clarify that in this context it is required that I compile this library separately.
Note There seem to be two related source files dump_ssse3.cpp and the mentioned dump_avx2.cpp file, do I have to compile only one of them? I cannot make out what to do from the Jamfile in the build folder :(
That looks like a bug in clang (LLVM). First, the intrinsic belongs to AVX2, not SSE4.2. Second, the whole dump_avx2.cpp file is compiled with -mavx2, so the required extensions are enabled. You can see the compiler switches in the error message from b2. And no, both dump_ssse3.cpp and dump_avx2.cpp should be compiled. The library does runtime detection of the available instructions in the CPU and selects the proper implementation.
Related
[Mac OS 10.13.2, Xcode9.2]
Clang has a flag -stdlib which, according to both clang++ -cc1 --help (same as clang -cc1 --help) and the LLVM documentation page, allows specification of the C++ standard library to use.
1) How does this flag impact on compilation? I.e. does it change the order of library include paths etc.
2) How does this flag impact linking? I.e. is it just a short-cut/alternative for supplying -lc++?
I am really interested in understanding the details of this flag because I can't find any documentation describing it's precise behaviour and it is causing havoc with our build system since the Xcode9 upgrade. Inclusion of -stdlib=libc++ in our Makefile causes the compilation to fail due to headers problems, yet, when -stdlib=libc++ is omitted, our projects compile fine (presumably because libc++ is the Mac OS default Standard C++ library). The project link against libc++ due to other linker flags -lc++ and -lsupc++.
Some background info about our use-case
We are using Clang to cross-compile to a -march=i686 -target i686-linux-elf target. Prior to the Xcode9 update, our build system was working fine. Since the upgrade we're getting compiler errors, such as:
/usr/local/our-target/sysroot/usr/local/include/c++/v1/stdlib.h:111:82: error: use of undeclared identifier 'labs'; did you mean 'abs'?
inline _LIBCPP_INLINE_VISIBILITY long abs( long __x) _NOEXCEPT {return labs(__x);}
I've now been able to fix this problem by changing the header include paths. Namely I have removed a path reference to the folder that is parent to both the libc++ AND gcc4.8.5 includes.
# -I${STAGING.nao}/usr/local/include/c++ \
-I${STAGING.nao}/usr/local/include/c++/v1
I am still very interested in understanding the details of what the flag does.
I am trying to work through this tutorial on OpenCL, on a Windows 10 dev system which has integrated Intel HD graphics. I have installed Intel's OpenCL SDK. I have added the include directory from the SDK install into Properties > C/C++ General > Paths and Symbols > Includes. I am using MinGW as my compiler for Eclipse
In response to a number of linker errors that popped up when I first tried to compile the project, I set up the linker in eclipse to point to opencl.lib as outlined in this answer.
That took care of the linker errors, but there's an offending line from the tutorial which makes it impossible for the tutorial boiler-plate to compile:
87 cl_int result = program.build({ device }, "");
Set up as I am, this gives me the following warning and error:
..\src\main.cpp:93:32: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11
..\src\main.cpp:93:45: error: no matching function for call to 'cl::Program::build(<brace-enclosed initializer list>, const char [1])'
If I'm reading this correctly (I haven't used C++ since before C++11 was a thing), the compiler is first warning me that it doesn't properly recognize what {device} is supposed to be (a vector of devices which has only one entry in it, initialized earlier in the code). Then, since it doesn't recognize {device}, the compiler errors out because it can't find a signature for cl::Program::build with arguments that match whatever-the-heck it's interpreting {device} to be.
Following the warning's advice, I followed the instructions given in this answer to add the -std=c++11 option for the compiler. However, when I do that the linker errors come back. Trying to compile with these options results in about thirty errors which all basically say they can't find any reference for the CL calls in the library files. For example:
C:/Program Files (x86)/Intel/OpenCL SDK/6.3/include/CL/cl.hpp:1753: undefined reference to `clGetPlatformInfo#20'
How do I make the compiler behave? I think I remember reading somewhere that the order of compiler options in the command line matters withe regards to linking, could that be messing up my compile since I added the -std=c++11 option?
I (sort of) figured out why the compiler was unhappy--the library I was linking was the x64 library for OpenCL installed in [base Intel dir]\OpenCL SDK\6.3\lib\x64, but (I think?) my compiler is not set up to create x64 apps. When I link to the .lib file in OpenCL SDK\6.3\lib\x86 my linker errors disappeared.
I am attempting to compile a C++ library for a Tegra TK1. The library links to TBB, which I pulled using the package manager. During compilation I got the following error
/tmp/cc4iLbKz.s: Assembler messages:
/tmp/cc4iLbKz.s:9541: Error: thumb conditional instruction should be in IT block -- `strexeq r2,r3,[r4]'
A bit of googling and this question led me to try adding -mimplicit-it=thumb to CMAKE_CXX_FLAGS, but the compiler doesn't recognize it.
I am compiling on the tegra with kernal 3.10.40-grinch-21.3.4, and using gcc 4.8.4 compiler (thats what comes back when I type c++ -v)
I'm not sure what the initial error message means, though I think it has something to do with the TBB linked library rather than the source I'm compiling. The problem with the fix is also mysterious. Can anyone shed some light on this?
-mimplicit-it is an option to the assembler, not to the compiler. Thus, in the absence of specific assembler flags in your makefile (which you probably don't have, given that you don't appear to be using a separate assembler step), you'll need to use the -Wa option to the compiler to pass it through, i.e. -Wa,-mimplicit-it=thumb.
The source of the issue is almost certainly some inline assembly - possibly from a static inline in a header file if you're really only linking pre-built libraries - which contains conditionally-executed instructions (I'm going to guess its something like a cmpxchg implementation). Since your toolchain could well be configured to compile to the Thumb instruction set - which requires a preceding it (If-Then) instruction to set up conditional instructions - by default, another alternative might be to just compile with -marm (and/or remove -mthumb if appropriate) and sidestep the issue by not using Thumb at all.
Adding compiler option:
-wa
should solve the problem.
I'm trying to run the example "Scale_Space_Surface_Reconstruction_3" from CGAL library on CodeBlocks IDE on Ubuntu platform, as it would be nice
to have the IDE support for code completion and a more automatic configuration process.
I managed to successfully execute it by compiling it with cmake on the terminal window.
However, on CodeBlocks, after creating a new project and copying the code from the example, I get the following error:
/usr/local/include/CGAL/Scale_Space_Reconstruction_3/Scale_Space_Surface_Reconstruction_Impl_3.h:165:23: error: variable or field 'pca' declared void
Approximation pca( _nn[i]);
By looking inside the code, I found out that this is due to an undefined Macro CGAL_EIGEN3_ENABLED. As my experiment shows, if I define the macro at
pre-processing time, I do not get the same error. That is because, by defining the macro, the type definition Default::Get< wA,void>::type, becomes
Default::Get< wA, Weighted_PCA_approximation_3<Gt>>::type, and the compiler does not complain any more.
Unfortunately, as a deserved prize for messing with things I do not really understand, I get a segmentation fault at runtime.
How should I change the compiler options of codeBlocks to make the compilation succeed, and the executable run successfully?
I have the following include paths:
/usr/local/lib/CGAL/ /usr/local/include /usr/include /usr/include/eigen3.
I also included the following libraries:
libCGAL.so, libCGAL_Core.so, libCGAL_ImageIO.so, libgmp.so, libmpfr.so, libtbb.so, libtbbmalloc.so, libtbbmalloc_proxy.so
I need to update boost libraries to version 1_46, currently Rad Studio XE/2010 have 1_39 version. When I try just to overwrite boost include path compile fails with various errors from Borland VCL. When i try to add new boost libs in other path keep previous version it also fails with compile condition errors when constructing std::* classes.
I need shared_memory_manager support that is available only in new boost versions. Is there any other ways to upgrade boost libraries or use shared memory that will be available to same processes?
Compilation errors when compiling with new boost version only:
[BCC32 Error] bad_weak_ptr.hpp(44): E2113 Virtual function 'bad_weak_ptr::what() const throw()' conflicts with base class 'std::exception'
[BCC32 Error] xlocale(953): E2228 Too many error or warning messages
There are dozens of locations inside of boost which check the compiler version in order to determine whether or not certain workarounds are needed. (checking against both __CODEGEARC__ and __BORLANDC__) You need to test each of these and update the version number as appropriate. Also there are a number of defines set inside the config/compiler/codegear.hpp file (typically BOOST_HAS_* and BOOST_NO_*) which you also need to turn on/off for different versions of the compiler.
It is a very tricky and time consuming process.