I have created a Qt Widgets Application project. In mainwindow.cpp, I want to add a C source file (mySource.c) from a library which includes some rules written in C language that is not allowed to compile with C++ compiler. One of the error which is appeared is:
error: invalid conversion from ‘const char*’ to ‘gchar* {aka char*}’
When I create a Plain C Application project in Qt, I can simply compile that source. So I need C compiler.
I also used the following code which does not solve the error:
extern "C" {
#include "mySource.c"
}
When I go to the Tools -> Options -> Kits -> Kits, I see Desktop Qt 5.12.0 GCC 64bit and after clicking on it I can see the C and C++ compiler as follows:
C: GCC(C,X86 64bit in /usr/bin)
C++: GCC(C++,X86 64bit in /usr/bin)
I have searched a lot and tested different solutions but I can not solve the problem. What is the solution? Is it a specific flag that I should enable in .pro?
Related
I am trying to include the Raspberry Pi Pico PIO/i2c example in a library within my larger project (to abstract i2c implementations). This seems to work just fine when it is included in a primary executable project (like to example). Within a library, I receive the following compilation error. pis_interrupt0 is a member of the pio_interrupt_source enum from the SDK. Both my main project and library project is using C++ -- while the PIO code is using just C.
In file included from /src/lib/lib_pico_i2c/pio_i2c.h:9,
from /src/lib/lib_pico_i2c/PioI2C.cpp:3:
/src/build/lib/lib_pico_i2c/i2c.pio.h: In function 'void i2c_program_init(PIO, uint, uint, uint, uint)':
/src/build/lib/lib_pico_i2c/i2c.pio.h:87:53: error: invalid conversion from 'uint' {aka 'unsigned int'} to 'pio_interrupt_source' [-fpermissive]
pio_set_irq0_source_enabled(pio, pis_interrupt0 + sm, false);
~~~~~~~~~~~~~~~^~~~
I suspect it has something to do with C++ conversion rules or a missing included of some sort. I have tried to manually include the SDK file that defines pio_interrupt_source with no change. I am relatively new with C/C++ (I do c# in my day job). My reading of C conversion behavior for enums is that there should be an implicit conversion (with no decorations needed). Does being referenced from a C++ file change this? I have tried a number of manual conversion methods with no luck.
you can see the code here: burtonrodman/pico-oled-pio-cpp
Thanks #Paul Saunders,
I have able to fix by adding this to my CMakeLists.txt:
set_source_files_properties(PioI2C.cpp PROPERTIES COMPILE_FLAGS -fpermissive)
set_source_files_properties(pio_i2c.h PROPERTIES COMPILE_FLAGS -fpermissive)
I'd like to run the ARToolKitX Calibration app on iOS. Unfortunately, the app isn't available in the App Store, so I assume I'd have to compile it myself. Luckily, I have an active Apple Developer account...
So I got the source code from GitHub:
git clone https://github.com/artoolkitx/artoolkitx-calibration
cd artoolkitx-calibration
Then I downloaded the ARToolKitX iOS library from https://github.com/artoolkitx/artoolkitx/releases/download and I followed the steps in the iOS section of the build.sh script to link this SDK to the Xcode project.
I opened the project with Xcode 9.3 on macOS High Sierra 10.13.3.
I downloaded the opencv2.framework library from SourceForge and linked it: https://sourceforge.net/projects/opencvlibrary/files/opencv-ios/
Xcode reported an issue in line 61 of prefs.hpp:
cv::Size getPreferencesCalibrationPatternSize(void *preferences);
'getPreferencesCalibrationPatternSize' has C-linkage specified, but returns user-defined type 'cv::Size' (aka 'Size_') which is incompatible with C
Any pointer to get a step further in this compilation process would be greatly appreciated!
I just had the same problem today. You need to make sure that your source code files, usually the '.c' and the '.h' files, are interpreted as C++ headers and sources. For this specific error, trace back which file calls cv::Size and change its type to C++ header/source.
The compilation issue was fixed by removing the following lines around the error-generating usage of cv::Size:
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif
I have created a C++ project in Xcode 8.2.1 with a Bridging Header file.
I have added a Point3.hpp and Point3.cpp file into a shared folder.
The types for the cpp and cpp files (in the identity and type inspector) are Default - C++ Source and Default - C++ Header respectively.
The LLVM 8.0 Language settings are:
C++11 [-std=c++11]
libc++ (LLVM C++ standard library with with C++11 support)
When I try to build the project, I find that I get the following error:
I have tried searching to find information to resolve this issue, but most seem to be related to compiling source that is a combination of objective-C and C++ whereas this project was setup as a Swift3 project with C++ bridge. Source code
ex3-Bridging-Header.h
#import "../../../Shared/ex3/math/Point3.cpp"
Point3.cpp
#include "Point3.hpp"
using namespace EX3;
Point3::Point3()
{
} ...
Point3.hpp
#ifndef EX3_POINT3_HPP
#define EX3_POINT3_HPP
namespace EX3
{
class Point3
{
public:
Point3(); ...
compiler settings
After continuing looking, I finally managed to find a working solution. There may be other ways to achieve this but I fixed it by routing the C++ through an Objective C layer. Whilst this seems a little bit clumsy (as it adds an extra bridge layer), as of Swift3, it is reported that there is no direct interop layer to C++.
we have an application which is written in c++ and now we are trying to use the same application on the ARM board for which we were provided a toolchain.
So when i do a test c++ project it compiles ok and code on the target is executed perfectly.
As we want to use also some of the functionality of the target (eg display,...), that part is for C, headers are C, libraries are C.
So when i tried including C headers i got a lot conversion errors (eg. Description invalid conversion from unsigned int' tostlv_type' locaion: tlv_tags.h C/C++ Problem)
For example function generating problems:
static inline
enum stlv_type _stlv_get_tag_type(unsigned int tag)
{
return STLV_GET_TYPE(tag);
}
When creating C project this all works without a problem, but c++ project hundreds of conversion errors.
So i tried to include this headers in extern "C" block without any success, still same problems.
So can somebody help me combine this :) as there is no possiblity to get c++ from the manufacturer and also changing headers is not an option as new platform releases can come at any time.
Thanks in advance!
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.