I'm setting up a C++17 + boost 1.76.0 project in Clion 2018.3, with this minimal code:
#include <boost/asio/ip/tcp.hpp>
int main(int argc, char **argv)
{
auto const address = boost::asio::ip::make_address(argv[1]);
return 0;
}
In my CMakeLists.txt I have correctly setup the C++ version:
add_definitions(-std=c++17)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17")
And the project compiles and run fine. But Clion shows the following error on the make_address line:
No member named 'make_address' in namespace 'boost::asio::ip'
CTRL-hover on the method name correctly shows the doc, and CTRL-click correctly opens the header file.
Are we supposed to do something else to tel Clion which C++ version are we using?
Looks like the IDE and compiler don't agree in the version of boost. These functions are not specific toi a language version, but I think were introduced in a relatively recent Boostt release
It turned out that I had 2 Boost versions installed on the system, one shipped with ROS (I didn't know that) and v1.76.0 that I compiled to get boost::asio. Looks like Clion was using the one of ROS which older.
Uninstalling v1.76.0 system-wide and adding it back as a header library in the project fixed these false errors, though Clion now takes forever to anaylise the code (despite I excluded the libs folder). Using only the version shipped with ROS would be the best solution for someone not needed the latest additions of Boost (but I do).
Related
I just updated my MacBook Pro to macOS Catalina 10.15, and tried to compile and run a C++ command line program, but I had a problem which didn’t exist on previous versions;
This is simply the code:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, World!\n";
return 0;
}
The code compiles and outputs the expected, but still the Xcode says:
fatal error: 'iostream' file not found
I tried changing the Build Settings/C++ Standard Library to libstdc++, but a warning says:
warning: include path for stdlibc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead
And the same iostream error still exists.
I'm compiling from the command line, and none of the answers listed here (or elsewhere) worked for me.
What does seem to work (so far) is to add the following to .profile or whatever script your terminal uses to start up: (zsh, csh, bash, etc.)
export C_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include
export CPLUS_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include
You will probably have to change MacOSX10.15.sdk whenever you upgrade your operating system.
C_INCLUDE_PATH and CPLUS_INCLUDE_PATH are options for the clang toolchain rather than MacOS environment, so hopefully this solution will work long-term, unlike xcode-select --install (which won't fix the include directories on an upgrade) or ln -s ... /usr/include (which is now forbidden by System Integrity Protection).
I had the same problem and used the following youtube video to fix it.
https://www.youtube.com/watch?v=hrPm7tWC-BI&feature=youtu.be
or you can follow this path. Make sure to include the quotation marks
Project - Build Settings - Search Paths - Headers Search Paths, and add the following path:
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/"
So, I restarted my laptop and everything seems to be fine right now, thanks for those who tried to help.
libstdc++ is not OK for Xcode Build & Compile time,
libstdc++ is OK for iPhone Run Time
From answer recommended by #Alan Birtles
libstdc++ Support was removed from the iOS 12.0 Simulator runtime, but
it remains in the iOS 12.0 (device) runtime for binary compatibility
with shipping apps.
I encountered this when declaration in .hpp file.
#include <iostream>
#include <string>
OK with
#ifdef __cplusplus
#include <iostream>
#include <string>
// usage code
#endif
I tried a fresh Catalina install with Xcode. I copied and pasted your code into "test.cpp" and then ran:
clang++ test.cpp
in the same directory as the "test.cpp" file from Terminal. The result was an "a.out" file which when run:
./a.out
output the required "Hello, World!" result. Hopefully that is of some use (as a point of reference).
I need to use C++ 17's filesystem header for my project. As far as I know, Apple finally made it available with Xcode 11 and with macOS Catalina. I'm on the latest (beta 3) Xcode 11 and I use macOS Catalina public beta 2, so in theory it should work. But for some reason it's not, and Xcode gives errors like:
'~path' is unavailable: introduced in macOS 10.15
If I set the C++ standard library in Build Setting to libstdc++ from libc++ these error emssages gone and I got a warning:
include path for stdlibc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead
and a ton of errors with missing iostream and cstddef in various files. What could I do to make filesystem work?
Edit: a minimal code example
#include <filesystem>
#include <iostream>
#include <string>
bool isPathDir(std::string pathString);
int main(int argc, char *argv[])
{
std::string pathString = "../test.jpg";
if (isPathDir(pathString)) {
std::cout << "This is a directory!" << std::endl;
} else {
std::cout << "This is not a directory" << std::endl;
}
}
bool isPathDir(std::string pathString)
{
std::filesystem::path path(pathString);
return std::filesystem::is_directory(path);
}
Promoting my comment into an answer:
Do you happen to have a back-deployment target older than macOS 10.15 specified? This would appear on your command-line as something like -mmacosx-version-min=<value>.
#LouisDionne Oh yes, that was the problem! As soon as I set the deployment target to 10.15 the code build perfectly! I've never heard of deployment targets before, thank you very much!
Just to explain what's going on here, the issue is that support for <filesystem> was only introduced in Mac OS 10.15. When you use -mmacosx-version-min=XYZ, you tell the compiler that your program should be able to run on versions of Mac OS all the way until version XYZ. If you use a version older than 10.15, we nicely tell you at compile-time that you can't use <filesystem>, because that would be a runtime error (likely symbol missing from libc++.dylib) if you tried running the program on a version of Mac OS older than 10.15.
First of all I'm quit new in programming in c/c++, so maybe it's just a basic error but i don't get it. The Problem is, I want to use libpcap in a bigger application, but i can't even integrate the libary into a simple HelloWorld.cpp. Atm I'm using Eclipse (MinGw Compiler) with Windows 64bit, but consindering to switch to Linux if my Problem(s) can't be solved.
Downloaded "libpcap-1.5.3.tar.gz" from tcpdump.org, extracted and added the root directory of the Libary to Eclipse (under "Properties/C|C++ Build" to all Compilers and to the MinGW Linker).
My Code:
#include <iostream>
#include <pcap.h>
#include <stdio.h>
using namespace std;
int main(int argc, char *argv[]) {
cout << "Hello World!!!" << endl; // prints Hello World!!!
char *dev = argv[1];
printf("Device: %s\n", dev);
return(0);
}
First error:
D:\Tools\MinGW\lib\libpcap/pcap-stdinc.h:49:22: fatal error: bittypes.h: No such file or directory
So I changed line 49 from
#include "bittypes.h"
to
#include <Win32/Include/bittypes.h>
(the actual location of bittypes.h) and next error pops up:
D:\Tools\MinGW\lib\libpcap/pcap/pcap.h:451:1: error: 'Adapter' does not name a type
'Adapter' is defined in "pcap-int.h" so I included this header into "pcap.h" but now I get:
D:\Tools\MinGW\lib\libpcap/pcap-int.h:46:22: fatal error: Packet32.h: No such file or directory compilation terminated.
and this "Packet32.h" does not exist...
I can't belive this popular libary is broken, so where is my mistake? Thanks in advance!
The Problem is, I want to use libpcap in a bigger application, but i can't even integrate the libary into a simple HelloWorld.cpp. Atm I'm using Eclipse (MinGw Compiler) with Windows
If you want to use libpcap on Windows, you need a version of libpcap that's been ported to Windows. The libpcap source won't build on Windows; on UNIXes, libpcap can and does use packet capture mechanisms built into the OS, but it doesn't do so on Windows (for one thing, older versions of Windows, at least, don't have a packet capture mechanism built in!), so it also needs a driver.
One port of libpcap to Windows is WinPcap; it includes the necessary driver. If you install WinPcap, and then download the WinPcap developer's pack and install it, it should be possible to configure Eclipse so that your program can be built with WinPcap.
libpcap-1.5.3.tar.gz is a source package for the library, not a binary package. So you need to build the library; you can't just add the directory to Eclipse and expect it to work.
The usual way to build a source package is to unpack it into a directory and look for a file called README or INSTALL, which is a simple text file containing instructions on how to build and install the package for various machines. Often there will be multiple such files for different platforms.
Generally, there will be a script called configure that you run to create a Makefile for your target; then you run make to build the code and make install to install it in a standard place so that other packages can find it.
The following code shoudn't produce an error:
#include <cstdlib>
#include <cstdio>
#include <iostream>
using namespace std ;
int main ( int argc , char** argv )
{
int n ;
cin >> n ;
cout << n ;
return 0 ;
}
Yet a get a "RUN FAILED (exit value -1,073,741,511, total time: 46ms)" whilst running MinGW/Msys on Netbeans. Any advice like switching back to Cygwin?
I recommend using MinGW Distro if you want to develop C++ under a Microsoft Windows operating system. It ships with a pretty new GCC version and with the Boost libraries.
NetBeans IDE is pretty picky regarding the build environment settings. E.g. It doesn't work together with all versions of make (we have to distinct make.exe from MSYS and mingw32-make.exe from MinGW for example) and there are problems regarding the used Java Runtime Enviroment (JRE).
With the settings shown in the following screenshot you should be able to build your example with MinGW Distro and NetBeans 8. I recommend to not configure a absolute path to the make.exe file but add that path to your Microsoft Windows environment variable PATH. Otherwise you may get build errors.
Maybe these two blog posts help if you want to use the "default" MinGW distribution:
Installing Minimum GNU for Windows (MinGW)
Configure NetBeans IDE for Minimum GNU for Windows (MinGW)
I hope this helps others as well.
Not related to your question: Don't use using namespace std:
#include <iostream>
int main(int argc, char** argv) {
int n;
std::cin >> n;
std::cout << n;
return 0;
}
I ran into this same issue (with exit code -1,073,741,511), so though a dated question, I'm posting this here for anyone else who runs into the problem.
Run the executable for the program manually. You might get an error such as "the procedure entry point __gx_personality_v0 coud not be located in the dynamic library libstdc++-6.dll". (OP has confirmed this in a comment.)
The .dll file referred to in the error message above is either not being linked, or linked incorrectly. The correct version of the .dll that needs to be linked is the one in the ...\MinGW\bin directory. In Windows, you can check the .dll file being linked by typing where libstdc++-6.dll in a command prompt; the first result that is listed will be the file that is linked. If you already see ...\MinGW\bin\libstdc++-6.dll as the first result here, my fix below will not help you.
If you see a message "INFO: Could not find files for the given pattern(s).", then ...\MinGW\bin needs to be added to your %PATH% variable. (OP has already confirmed this was not the issue.)
The issue I was having was that a program I had installed had its own (likely outdated) version of libstdc++-6.dll, which was in a folder also included in my %PATH% variable, ahead of ...\MinGW\bin. This meant that this other .dll file was being picked up and linked to during execution. This can be fixed by editing your %PATH% variable to make sure the ...\MinGW\bin entry is ahead of all other directories that also have a version of the .dll file.
Edit: The other option is to statically link the .dll at program compilation, or place a copy of the correct .dll in the program executable directory. However, neither of these fixes is 'global', and needs to be done for each project individually.
Hope this helps!
I'm not sure why this is, but 99% of the problems I have with programming in C++ have to do with the gcc linker.
I want to link the Qt library to a project in CodeLite. This is the code I have so far:
#include <QApplication>
int main(int argc, char *argv[])
{
return 0;
}
When I compile, I get the error
/Users/andrew/Dev/C++/COSC 102/elitecod/main.cpp:1:24: error: QApplication: No such file or directory
I have Qt installed (with Homebrew, Mac OS X Lion) in /usr/local/include. Why is this happening, and how can I fix this problem?
The error indicates it can't find the file QApplication. You need to add the Qt 'include' directory to the list of places the compiler should look for it and other header files.
A brief google seems to indicate you may have other problems with Qt, you might want to keep this link handy.