I've successfully installed MySQL, Boost and mysql-connector-c++ on my macOS High Sierra 10.13.3 via Homebrew, but i've ran into problems with using those libs in Xcode.
So, my boost and connector libs are located at /usr/local/Cellar/. So i just wrote a simple code sample to check if everything "works":
#include <mysql_driver.h>
#include <mysql_error.h>
#include <mysql_connection.h>
int main()
{
return 0;
}
and compiled it with
c++ -I /usr/local/Cellar/mysql-connector-
c++/1.1.9_1/include/mysql_connection.h /usr/local/Cellar/mysql-connector-
c++/1.1.9_1/include/mysql_driver.h /usr/local/Cellar/mysql-connector-
c++/1.1.9_1/include/mysql_driver.h main.cpp
Everything seems to be working, except I get some warnings:
clang: warning: treating 'c-header' input as 'c++-header' when in C++ mode,
this behavior is deprecated [-Wdeprecated]
clang: warning: treating 'c-header' input as 'c++-header' when in C++ mode,
this behavior is deprecated [-Wdeprecated]
But that's not a huge issue, I think.
And then I try to use those libs in Xcode, so i do this:
Yet when I try to compile any code with those libs in Xcode, I get this:
'boost/scoped_ptr.hpp' file not found with include; use "quotes" instead'
and many errors alike for boost and mysql-connector-c++. Obviosly, changing all <> to "" in source files is NOT a good idea, futhermore, it's extremely tiring.
How to fix this error?
Related
System OSX 10.14.6, macbook pro
Trying to compile this simple C++ program:
#include <iostream>
int main() {
sdt::cout << "hello world" << std::endl;
return 0;
}
Have gcc 9 installed via homebrew, as well as XCode command line tools.
Both of the following work
c++ main.cpp
g++-9 main.cpp
Trying out the latest Intel Parallel Studio, the following fails:
> icpc main.cpp
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/iosfwd(90),
from /Library/Developer/CommandLineTools/usr/include/c++/v1/ios(215),
from /Library/Developer/CommandLineTools/usr/include/c++/v1/iostream(38),
from main.cpp(1):
/Library/Developer/CommandLineTools/usr/include/c++/v1/wchar.h(119): catastrophic error: cannot open source file "wchar.h"
#include_next <wchar.h>
^
compilation aborted for main.cpp (code 4)
Can someone tell me what I am missing here?
EDIT RESPONSE TO COMMENT ABOUT find
searching from / for wchar.h yields many wchar.h files, including the one from the error:
./usr/local/Cellar/gcc/9.2.0_3/include/c++/9.2.0/tr1/wchar.h
./Library/Developer/CommandLineTools/usr/include/c++/v1/wchar.h
./Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/wchar.h
./Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS.sdk/usr/include/wchar.h
./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/wchar.h
./Applications/Xcode.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS.sdk/usr/include/wchar.h
./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/wchar.h
./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/DriverKit19.0.sdk/System/DriverKit/usr/include/wchar.h
./Applications/Xcode.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator.sdk/usr/include/wchar.h
./Applications/Xcode.app/Contents/Developer/Platforms/AppleTVSimulator.platform/Developer/SDKs/AppleTVSimulator.sdk/usr/include/wchar.h
./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/wchar.h
./Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/wchar.h
./opt/intel/intelpython3/include/c++/v1/support/solaris/wchar.h
./opt/intel/intelpython3/include/c++/v1/wchar.h
./opt/intel/intelpython3/pkgs/libcxx-4.0.1-hcfea43d_1/include/c++/v1/support/solaris/wchar.h
./opt/intel/intelpython3/pkgs/libcxx-4.0.1-hcfea43d_1/include/c++/v1/wchar.h
./dev/fd/3/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS.sdk/usr/include/wchar.h
./dev/fd/3/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/wchar.h
./dev/fd/3/Applications/Xcode.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS.sdk/usr/include/wchar.h
./dev/fd/3/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/wchar.h
./dev/fd/3/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/DriverKit19.0.sdk/System/DriverKit/usr/include/wchar.h
./dev/fd/3/Applications/Xcode.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator.sdk/usr/include/wchar.h
./dev/fd/3/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVSimulator.platform/Developer/SDKs/AppleTVSimulator.sdk/usr/include/wchar.h
./dev/fd/3/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/wchar.h
./dev/fd/3/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/wchar.h
./dev/fd/3/opt/intel/intelpython3/include/c++/v1/support/solaris/wchar.h
./dev/fd/3/opt/intel/intelpython3/include/c++/v1/wchar.h
./dev/fd/3/opt/intel/intelpython3/pkgs/libcxx-4.0.1-hcfea43d_1/include/c++/v1/support/solaris/wchar.h
./dev/fd/3/opt/intel/intelpython3/pkgs/libcxx-4.0.1-hcfea43d_1/include/c++/v1/wchar.h
As per the comments, this solved the problem:
icpc main.cpp -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
Intel C++ compiler on macOS is highly sensitive to the version of Xcode being used. For example, I receive the same errors as above when using icpc 2020 Initial Release and Xcode 11.3.1, but the code compiles and executes just fine with "icpc main.cpp" when using Xcode 11.2.1.
This has been the situation with Intel C++ compilers for some time on macOS... check your Xcode version and try again.
I just started using MinGW for Windows. When trying to create executable using
g++ a.cpp -o a.exe -std=c++14
for the code below:
#include <string>
using namespace std;
int main()
{
string x = to_string(123);
return 0;
}
I'm getting following error:
C:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../libmingwex.a(vsnprintf.o):(.text+0x0): multiple definition of vsnprintf
C:\Users\..\Local\Temp\cc4sJDvK.o:c:/mingw/include/stdio.h:426: first defined here
collect2.exe: error: ld returned 1 exit status
What is the root cause for this error and how can I make it go away? While I can easily find a replacement for to_string() function I'm not sure what is causing this error to occur in the first place.
Installing MinGW packages mingw32-libmingwex-* will link an appropriate version of vsnprintf and avoid the linker error.
This issue, i.e. multiple definition of vsnprintf, still exists in MinGW as December 2019.
After investigating a lot, I found the solution in the official mailing list.
It's a bug in mingwrt-5.2.2. Downgrading to the mingwrt-5.2.1 version solves that issue.
To do that, just input the following command:
mingw-get upgrade mingwrt=5.2.1
Then restart the MinGW shell.
Read the full story here.
Note: MinGW-w64 and MinGW are separate projects, so the accepted solution is not so helpful to me, as I want to keep MinGW and not to move to MinGW-w64.
I solved this issue using MinGW w64 compiler
download mingw-w64-install.exe
setup to Version: 6.3.0, Architecture: i686, Threads: posix, Exception: dwarf and Build revision: 2.
I hope this will be of some help.
There are multiple definitions of vsnprintf in both stdio.h and libmingwex.a. I am able to work this around by adding #define __USE_MINGW_ANSI_STDIO 0 to the start of the code, before any includes, which disables the definition of vsnprintf in stdio.h.
In Eclipse I am using mingw-w64 V5.3.0 as the compiler and I have enabled C++11 (which was the solution in the following related post here and here). My compilation command looks as follows (from eclipse console window):
g++ -std=c++11 -O0 -g3 -Wall -c -fmessage-length=0 -o "src\Launch.o" "..\src\Launch.cpp"
The simple code I am attempting to run is as follows:
#include <stdio.h>
#include <iostream>
#include <string>
int main()
{
std::string test = std::to_string(0);
std::cout <<"HI" << std::endl;
return 0;
}
The program compiles but for an error stated in the question. Running it without the to_string line works fine. There have been suggestions back in 2012 that MingW has a problem with to_string(), but was resolved in later versions has shown here.
Screen shot below:
And the console output is as follows:
The following is the error I receive when running the code from the .exe directly:
As mentioned in the comments, the issue is a linking issue, however it is linking correctly to iostream which is in the same directory as string.
Eclipse was looking in System32 for the library and driver files, despite PATH and Eclipse pointing to the MingW64 compiler on the computer. Eclipse is also showing it is linked to the MingW64 libraries correctly as the path to the headers when right-clicking and opening deceleration is shown to be correct. Why then it looks in System32 for the library at run-time I don't understand.
The problem was 'solved' by copying the entire MingW64 compiler driver folder into the System32 folder on Windows.
Earlier, I posed a related question.
I have the following program extracted from a large project in my Mac OS
#include <iostream>
int main(){
std::cout<<"hello"<<std::endl;
return 0;
}
Compiling it with Clang fails with the following error:
$ clang test.cpp
test.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^
1 error generated.
For information,
A) I have already installed xcode command line tools, using xcodeselect --install. But it seems iostream does not locate in the default search path of clang.
B) Using g++ instead of clang compiles the program. But in my problem, I am not allowed to use other compiler than clang, or to change the source program.
C) I can see workaround techniques, e.g, by tweaking the search path in .bashrc or with some symbolic link, etc. But I feel reluctant to use them, because it seems that I have an installation problem with my Clang and tweaking the path only helps to avoid one of these path issues.
clang and clang++ do different things. If you want to compile C++ code, you need to use clang++
Alternatively you can invoke c++ compiler directly by providing language name explicitely:
clang -x=c++
I want to use Clang and LibTooling to create some C++ source analysis and transformation tools. I've built Clang and LibTooling following this tutorial, and I've been able to run and create some analysis tools and compile C++ programs using the Clang binary I built. However, if I include headers from the standard library (in either source files or my tools), I run into issues when compiling or running the source files/tools. For instance, if I run clang-check on the following C++ source file:
#include <iostream>
int main() {
std::cout << "Hello";
return 0;
}
I get "fatal error: 'iostream' file not found". (Note: I can compile C++ programs, e.g. ones with user-defined classes, just not C++ programs using the standard library.) In an attempt to resolve the issue, I built libc++ (following this guide, building it in the llvm/project directory where I built LLVM and Clang), but I'm still having trouble getting Clang and the tools to use libc++. Now, if I try to compile a test file using:
export CPLUS_INCLUDE_PATH="~/clang-llvm/llvm/projects/libcxx/include"
export LD_LIBRARY_PATH="~/clang-llvm/llvm/projects/libcxx/lib"
~/clang-llvm/llvm/build/bin/clang++ ~/Documents/main.cpp
Then I get "fatal error: 'unistd.h' file not found". So my question is this: how do I properly point Clang and my tools to use libc++?
I am running OS X Yosemite 10.10 and using Clang 3.6.0.
Clang comes with some custom includes. So usually you have clang in
/usr/bin/clang++
and the includes in
/usr/lib/clang/3.6.1/include
but clang looks for them as a relative path:
../lib/clang/3.6.1/include
so make sure this relative path is accessible from either the clang++ binary, or your libtooling application.
Include your tool into this:
#include "clang/Tooling/CommonOptionsParser.h" // For reading compiler switches from the command line
#include "clang/Tooling/Tooling.h"
static cl::OptionCategory MyToolCategory("SearchGlobalSymbols");
static cl::extrahelp MoreHelp("\nMore help text..."); // Text that will be appended to the help text. You can leave out this line.
/* Your code (definition of your custom RecursiveASTVisitor and ASTConsumer) */
/* Define class MyASTFrontendAction here, derived from ASTFrontendAction */
int main(int argc, const char **argv)
{
/* Your code */
CommonOptionsParser op(argc, argv, MyToolCategory); // Parse the command-line arguments
ClangTool Tool(op.getCompilations(), op.getSourcePathList()); // Create a new Clang Tool instance (a LibTooling environment)
return Tool.run(newFrontendActionFactory<MyASTFrontendAction>().get()); // Run custom Frontendaction
}
The CommonOptionsParser allows you to read commands from the command line that are passed to the compiler.
For example, you can now call your tool like this:
your-tool yoursourcefile.c -- -nostdinc -I"path/to/your/standardlibrary"
Everything after the double dash will be passed to the compiler. Possible flags are described here:
http://clang.llvm.org/docs/CommandGuide/clang.html
-nostdinc tells the Preprocessor not to look for standard include paths. You can specify you own paths instead after -I.
Hope it helped someone :) Ask me if I wasn't specific enough.
Did you move/rename any of the parent directories after building/installing? The compiler should have been configured to know where to look for its standard libraries without having to specify the environment variable paths.
Use homebrew and install llvm using the command
brew install llvm
Your problem should be solved.