I need to use MathGL (mathgl.sourceforge.net) for plotting graphs in my Objective-C project but I cant compile it because of semantic issues in files datac_cf.h and canvas_cf.h like:
/usr/local/include/mgl2/datac_cf.h:80:17: 'mgl_datac_get_value' has C-linkage specified, but returns user-defined type 'dual' (aka 'complex<mreal>') which is incompatible with C
/usr/local/include/mgl2/datac_cf.h:206:17: 'mgl_datac_linear' has C-linkage specified, but returns user-defined type 'dual' (aka 'complex<mreal>') which is incompatible with C
/usr/local/include/mgl2/canvas_cf.h:494:17: 'mgl_cexpr_eval' has C-linkage specified, but returns user-defined type 'dual' (aka 'complex<mreal>') which is incompatible with C
there are 7 of them everytime on the "dual MGL_EXPORT ..." line
I have MathGL succesfully compiled using cmake and configured Xcode project header search path to "/usr/local/include" and library search path to "/usr/local/lib", I also dragged and dropped libmgl.7.0.0.dylib to my project..
How can I get rid of these semantic issues please?
I'm using FreeBSD and I have a similar problem. The simplest way to get rid of these warnings is to compile your dependent program with -Wno-return-type or more specifically, with -Wno-return-type-c-linkage flag, which suppresses these warnings.
Other than that, you can patch the headers.
Related
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 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.
I’m building a Cocos2d-x game for Android on a Mac, using Android NDK, and I get many warnings like this when compiling the C++ part:
/usr/include/module.map:1662:22: warning: unknown attribute 'extern_c' [-Wignored-attributes]
Is it dangerous? How can I fix it?
I'm guessing that extern_c is a compiler directive for the module map saying it is referencing functions from C++ that were written in the C language (different call frame structure).
The LLVM portion of the CLANG compiler is probably having a version mismatch.
http://clang.llvm.org/docs/Modules.html#module-maps
Try a command line $ clang -v
You may have to verify the compiler library version
xcode->preferences->locations->command line tools.
Ultimately you will want to clear this up so your stack frames match the arguments and your not referencing a C language function.
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've been trying to learn unit testing on my own following along a book.
Code in the book use the C++11 standard and have a line like this:
auto variable = function(parameter);
When I first compiled it I got this warning:
warning: 'auto' changes meaning in C++11; please remove it [-Wc++0x-compat]
No biggie, I could fix that by checking the following box in the Project->Build options... menu:
[ ] Have g++ follow the C++ 11 ISO C++ language standard [-std=c++11]
Now, however, I get new errors related to Google Mock in the gtest-port.h :
| | In function 'int testing::internal::posix::StrCaseCmp(const char*, const char*)':
|1719| error: '_stricmp' was not declared in this scope
| | In function 'char* testing::internal::posix::StrDup(const char*)':
|1721| error: '_strdup' was not declared in this scope
| | In function 'FILE* testing::internal::posix::FDOpen(int, const char*)':|
|1779| error: 'fdopen' was not declared in this scope
Searching for this problem yielded little for me but I did try and define the target OS as it was a suggested solution in case it was not correctly identified automatically. Adding GTEST_OS_WINDOWS=1 and/or GTEST_OS_WINDOWS_DESKTOP=1 in the projects defines changed nothing.
I realize this is easily fixed in this instance by just providing the correct type instead of using auto but I'd like to find a solution for this if possible. Replacing auto and not having the -std=c++11 option checked makes the code work as intended so the library works.
I'm using Code::Blocks 13.12 , MinGW/g++ 4.8.1-4 and Google Mock 1.7 in Windows.
Thanks for reading =)
The answer here lies in the functions which are missing declarations: _stricmp, _strdup and fdopen. The first two are Microsoft versions of the POSIX functions stricmp and strdup. Note that you are specifying the use of the C++11 ISO standard which does not contain items in the POSIX standard. By specifying --std=gnu++11 you are telling the compiler to accept a hybrid of C++11 and POSIX along with GNU extensions.
Interestingly I cannot replicate this with GCC 4.8.2 on Linux so there is the possibility that something else is going on in the Google Mock headers when compiling on Windows.
Answering for anyone still facing the same issue:
The source of this issue might be in your CMakeLists file.
Set your compiler flags to -std=gnu++ instead of -std=c++
One way to do it would be to include
set(CMAKE_CXX_FLAGS "-std=gnu++0x")
to your CMakeLists file.