I installed boost following instructions here: https://phylogeny.uconn.edu/tutorial-v2/part-1-ide-project-v2/setting-up-the-boost-c-library-v2/#
works in Visual Studio, but doesn't work when compiling using mingw g++ in windows cmd.
Editor is vim.
source code is like:
#include <boost/algorithm/string.hpp>
...
compiling like this:
> g++ -o test test.cpp
test.cpp:7:10: fatal error: boost/algorithm/string.hpp: No such file or directory
#include <boost/algorithm/string.hpp>
How can I make my mingw g++ available for boost?
You used the config from the page:
import option ;
using msvc ;
option.set keep-going : false ;
libraries = --with-program_options --with-regex --with-filesystem --with-system ;
using msvc should probably tell you something. It uses the MSVC toolchain. Because these are not interoperable (different C++ runtime libraries, for starters, different ABI likely), you can't link to those libraries.
Header Only
If, like the code you showed, you only require headers, then that is no issue, just add the include path to your compiler flags, as the tutorial also told you:
So either typing command line options directly:
g++ -I C:\boost_1_65_0
Or adding to a variable in your build script(s), like Makefile:
CPPFLAGS+=-I C:\boost_1_65_0
Or CMake:
INCLUDE_DIRECTORIES(C:\boost_1_65_0)
With Linking
To use pre-built shared libraries, you need to build different versions for mingw. See e.g. these steps: https://gist.github.com/zrsmithson/0b72e0cb58d0cb946fc48b5c88511da8
I installed from that last week (context) and it worked fine. (I also ended up going no-IDE with Vim, though VsCode was ok as well)
Check that it is using the mingw toolchain (e.g. mgw81) which also means that mgw81 shoud be part of the library filenames. Following just that tutorial already gives you this, but your previously existing configs might interfere if you're not careful.
Related
I'm trying to compile CMake using a non-default GCC installed in /usr/local/gcc530, on Solaris 2.11.
I have LD_LIBRARY_PATH=/usr/local/gcc530/lib/sparcv9
Bootstrap proceeds fine, bootstrapped cmake successfully compiles various object files, but when it tries to link the real cmake (and other executables), I get pages of "undefined reference" errors to various standard library functions, because, as running the link command manually with -Wl,-verbose shows, the linker links with /usr/lib/64/libstdc++.so of the system default, much older GCC.
This is because apparently CMake tries to find curses/ncurses libraries (even if I tell it BUILD_CursesDialog:BOOL=OFF), finds them in /usr/lib/64, and adds -L/usr/lib/64 to build/Source/CMakeFiles/cmake.dir/link.txt, which causes the linker to use libstdc++.so from there, and not my actual GCC's own.
I found a workaround: I can get the path to proper libraries from $CC -m64 -print-file-name=libstdc++.so then put it with -L into LDFLAGS when running ./configure, and all works well then.
Is there a less hacky way? It's really weird that I can't tell GCC to prioritize its own libraries.
Also, is there some way to have CMake explain where different parts of a resulting command line came from?
UPDATE:
I've written a detailed tutorial that incorporates the top two answers on this question: http://blog.johannesmp.com/2015/09/01/installing-clang-on-windows-pt1/
TL;DR
On Windows, Given the following program:
#include <iostream>
int main()
{
int arr[] = {1, 2, 3, 4, 5};
for(auto el : arr)
{
std::cout << el << std::endl;
}
return 0;
}
I want to be able to do the following:
clang++ hello.cpp -o hello.exe -std=c++14
And get a 64 bit executable that just works. I don't want to have to append a ton of -I includes to tell clang where to find iostream or other standard c++ headers; I don't want to have to link in multiple steps.
I don't care so much about performance, efficiency, what linker is used, etc. I just want to be able to have clang/gcc/whatever set up correctly so that I can use a single, quick and dirty, console command like the one above.
What do I need to install for that to just work?
The Problem
As a predominately mac/linux user I'm used to being able to just use a package manager to install the latest version of clang, which just works.
I'm now trying to set up clang/gnu compiler on windows and it seems to be far more difficult, If only because there is little to no straightforward documentation out there (that I've been able to find)
I've tried to follow this tutorial: https://yongweiwu.wordpress.com/2014/12/24/installing-clang-3-5-for-windows - and was able to use it to get clang to build and link (using gcc 4.8.2), but the resulting binaries were 32 bit.
I've tried installing the latest prebuilt binaries of clang (3.6.2) and the 64 bit version of mingw-w64 (4.9.3 for 64 bit with posix and sjlj for exceptions), and am getting:
hello.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^
1 error generated.
Which seems to indicate that clang is not seeing gcc's files. It seems that some versions of LLVM/clang are looking for only certain versions of gcc, but that doesn't seem to be documented anywhere?
Similarly someone mentioned to me on the LLVM IRC that you need to modify clang's driver to look for gcc in certain paths?
What I'm looking for
I'm fine with building LLVM/Clang from source if necessary, but I'm really just looking for clear, step-by-step instructions that allow me to use clang++ as easily as I'm able to do with mac/linux
Something like:
Build this version of LLVM/Clang and place it in that directory
Download and install this version of cygwin (or mingw32 or mingw-w64) and install these packages.
etc..
Try installing MSYS2 and then installing the mingw-w64-x86_64-clang (binary) package:
pacman -S mingw-w64-x86_64-clang
It is a bit old at the moment (3.6.2), but it might be good enough for you. Then when you run the Win64 shell provided by MSYS2, clang will be on your path.
If it's not good enough, I have recently been building a 64-bit version of clang with MSYS2 and using it to compile native 64-bit Windows executables. My process was something like:
Use pacman to install base-devel, mingw-w64-x86_64-ninja, mingw-x86_64-cmake and perhaps some other packages that are needed by the build process.
Grab my PKGBUILD script for clang and the files in the same directory. This is based on the mingw-w64-clang-svn package from MSYS2, which is largely the work of Martell Malone. You can find him on the MSYS2 IRC channel and ask him more about it.
In a Win64, shell, go to the directory with my PKGDUILD, run export MINGW_INSTALLS=mingw64 (so you are only compiling the 64-bit version), and then run makepkg-mingw.
It is unlikely you will get everything right on the first try, and some files might need to be edited. Clang may have changed since the last time I did this and some patches might not apply cleanly.
if you use the upcoming clang 3.7.0, simply set PATH to include mingw-w64's bin, clang will work as you expect
You can install llvm pre-release binary for Windows here. MinGW-w64 can be downloaded here. Of course, you should make sure the paths are properly set up.
For the latest version of clang, e.g., clang 6.0.0. The above solution by #user5271266 will not be enough. Now the default target for clang Windows is x86_64-pc-windows-msvc (Assume that you are using 64 bit Windows).
In order to compile C++ source files, according to here, we should change the target:
clang++ -target x86_64-pc-windows-gnu -std=c++14 test.cc -o test.exe
I've done everything, and it's payed off.
Trying to compile a mex file from MATLAB using the Windows 7.1 SDK.
~ I've created an compiled my C source code on GCC
~ I've created a MEX file that links and compiles fine via GCC on both Linux and OS X. Does not crash MATLAB, gateway function works fine
~ After much confusion, I switched my dev platform form 64-bit to x86 Win7
~ I've found .dll built files, but they do not link. Linking libs in MATLAB using MATLAB's linker flags will default to .lib, so...
~ I've found--after much googling--simple, pre-compiled x86 GSL .lib's and source files and linked them with MATLAB, eliminating any gsl_blas.h-and-it's-dependencies unrecognized external symbol errors
~ I've re-written every single variable declaration in my source code such that it is C89 standard compatible
~ I've set linker flags appropriately to avoid LIBCMT and any other LIB conflicts
~ I've installed the 2010 and 2012 VC C Runtime libraries
~ I've checked to make sure I have msvcrt.dll and msvcp60.dll in my System files
~ I've followed multiple tutorials online on how supposedly link everything together, most of which had nothing broken links or un-replicable results. I didn't find much to go off of for Cygwin or MinGW.
~ I've tried using the Lcc-win32 2.4.1 compiler
If I was doing basic matrix and vector operations, I'd be set, but unfortunately the various decomposition routines I'm utilizing require parts from the cblas library, which I linked as well, but I get ~30 errors all reporting the same thing...
cblas.lib(ctrsv.obj) : error LNK2001: unresolved external symbol __libm_sse2_sqrt_precise
Here's my MATLAB command.
mex -largeArrayDims -IC:\gsl\include -LC:\gsl\lib -lgsl -lcblas LINKFLAGS="$LINKFLAGS /NODEFAULTLIB:libcmt.lib" file1.c file2.c
So, out of options and frustrated out of my mind, I (naturally) come to stack overflow. Anyone have any idea how to solve this one? The only thing I've foudn on google points to wineHQ errors, not very helpful.
And, if possible, I'd rather not try to compile first on VS201X. I have access to whatever version I need, if necessary, but to me that just seems like a redundant step. Maybe I'm spoiled with Unix-based file system management and linking, though.
It's easy to compile the GSL library under MinGW, in fact the process of compiling from sources is exactly identical to that in Linux. Here are the steps I took:
Setup MinGW for Windows. I am using MinGW-w64 but there is also the popular TDM-GCC distribution which comes with a friendly web-installer.
Obtain GSL sources, and extract the tarball (gsl-1.16.tar.gz is the latest as of now)
Compile as usual, I've used the following commands:
$ ./configure --host=x86_64-w64-mingw32 --prefix=/mingw/local --enable-shared --enable-static
$ make
$ make install
It should take several minutes to finish. Maybe you can enable parallel builds to speed up compilation (make -j)
You'll end up with the necessary files installed in /mingw/local with the usual structure underneath (bin, lib, include).
Finally you can compile an example program with:
$ export PATH=/mingw/local:$PATH
$ gcc `gsl-config --cflags` -o main main.c `gsl-config --libs`
Of course if you prefer using Visual C++ as compiler, people out there have prepared solutions to build GSL using Visual Studio (either manually created project files, or using a build system like CMake and the like). See this question for such projects.
A third option is using Cygwin.
[Shamelessly cross-posted from the CMake help list]
I'm trying to create binaries as statically as possible. The fortran code I've got has got X11 and quadmath as dependencies, and I've come across a number of issues (maybe each of these issues should be in a different question?):
My variables are currently
set(CMAKE_LIBRARY_PATH /usr/X11/lib /usr/X11/include/X11 ${CMAKE_LIBRARY_PATH})
find_package(X11 REQUIRED)
find_library(X11 NAMES X11.a PATHS /usr/X11/include/X11/ /usr/X11/lib)
find_library(X11_Xaw_LIB NAMES Xaw Xaw /usr/X11/include/X11/ /usr/X11/lib ${X11_LIB_SEARCH_PATH})
find_library(Xaw Xaw7 PATHS ${X11_LIB_SEARCH_PATH})
set(CMAKE_LIBRARY_PATH /usr/lib/gcc/x86_64-linux-gnu/4.7 /usr/lib/gcc/x86_64-linux-gnu/4.7/x32 /usr/lib/gcc/x86_64-linux-gnu/4.7/32 ${CMAKE_LIBRARY_PATH})
find_library(quadmath NAMES quadmath.a)
set(BUILD_SHARED_LIBS ON)
set(CMAKE_FIND_LIBRARY_SUFFIXES .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
set(LINK_SEARCH_START_STATIC TRUE)
set(LINK_SEARCH_END_STATIC TRUE)
set(SHARED_LIBS OFF)
set(STATIC_LIBS ON)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static")
Using these, CMake attempts to build every program statically (as expected) - however, it fails because I don't have Xaw.a - I can't find out whether this actually should exist. I have installed the latest libxaw7-dev which I was expecting to fix it. One option would be to compile the X11 libraries myself, but I don't really want to do that...
if I comment out only set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static"), then CMake compiles everything, but uses shared libraries for every program, even though I specify the location of .a X11 libraries in my find_library() calls. I was expecting CMake to use the .a files where it could and then only use shared libraries - is there a way to force this behaviour?
does anyone know yet of a fix for the bug described here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46539; whereby gfortran seemingly can't statically link libquadmath? I tried the fix using gcc but I can't get CMake to recognise the libgfortran flag:
cmake -DCMAKE_Fortran_COMPILER=gcc -DCMAKE_Fortran_FLAGS=-gfortran
results in
-- The Fortran compiler identification is unknown
-- Check for working Fortran compiler: /usr/bin/gcc
-- Check for working Fortran compiler: /usr/bin/gcc -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:54 (message):
The Fortran compiler "/usr/bin/gcc" is not able to compile a simple test program.
However, as you might have noticed, I set the location of the libquadmath.a; when I build a program which doesn't use X11 but does use quadmath when I use
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static")
then the program does compile successfully (running ldd reports 'not a dynamic executable') - does this mean that the bug has been fixed, or does it only work because I set the location in CMake?
I was having a similar problem. Turns out that cmake was implicitly linking against libgfortran and libquadmath. To fix this I put the following in my top level CMakeLists.txt:
unset(CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES)
I could then explicitly link again the libraries using:
SET_TARGET_PROPERTIES(main_f PROPERTIES LINKER_LANGUAGE "C"
LINK_FLAGS
"/usr/local/Cellar/gcc/7.1.0/lib/gcc/7/libgfortran.a
/usr/local/Cellar/gcc/7.1.0/lib/gcc/7/libquadmath.a -lm -lgcc"
)
The static version of libgfortran is necessary because the shared library also depends on libquadmath. The added "-lm" and "-lgcc" bring in the system dynamic versions of these libraries. On a mac system, you would want to use the full path to your libm.a as well.
I guess your questions are not that much related, I don't know the answer for all of them.
For your static linking problems, since you're using GCC, you can pass multiple -static and -dynamic flags to it:
set(CMAKE_EXE_LINKER_FLAGS "-static ${STATIC_LIBS} -dynamic ${EVERYTHING ELSE} -static ${MORE_STATIC_LIBS}")
I don't know why Xaw.a isn't available on your system, probably because the package maintainer of your Linux distribution didn't really make them available.
Also, compiling everything static might make things not compatible between all distros out there and you cripple the ability for others to use improved, up-to-date libraries with your program, it might not be what you want.
If you intend to make a self-contained package of your program, it might be better just to include the shared libraries you used together, like Dropbox and many other proprietary applications do (Humble Bundle games are other example).
I followed instructions at http://clang.llvm.org/get_started.html
I compiled latest trunk of llvm and clang with MSVC 2010. Now I can compile simple programs with Clang but when I tried to compile this program I got a lot of errors.
Here is program:
#include <algorithm>
int main(){ return 0; }
And here are some of errors:
In file included from hello.cpp:1:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\algorithm:6:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\memory:987:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\intrin.h:24:
In file included from H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\immintrin.h:32:
In file included from H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\xmmintrin.h:988:
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1384:22: error: expected expression
return (__m128)__in;
^
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1390:23: error: expected expression
return (__m128i)__in;
^
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1396:23: error: expected expression
return (__m128d)__in;
^
Complete output from Clang: http://pastebin.com/qi87K8qr
Clang tries to use MSVC headers but it doesn't work. Maybe I should use libc++ or libstdc++ instead, but how to do that?
Note I'm not interested in precompiled clang binaries
Yes, clang simply does not support all of Microsoft's extended C++ syntax, and therefore cannot parse Microsoft's C++ headers which use that syntax. Not only that but Clang also doesn't have complete support for Microsoft's C++ ABI, name mangling, etc. I believe Clang on Windows works alright with C, however.
To use a different C++ standard library instead you can make clang ignore the normal header and library directories with, IIRC, -nostdinc++ and -nostdlib++. Then you can tell clang the include and library directories you want to use (using -isystem or -I or whatever). However I'm not sure whether libc++ or libstdc++ work under those circumstances, since they probably depend on things that the Windows C runtime library does not have.
Chandler Carruth mentioned at Going Native 2013 that there are now alpha builds of clang for Windows with Visual Studio integration. Lots of stuff is broken, for example, streams (so good old hello world won't work). However, there is a lot of effort being put into making clang work on Windows, so expect it to get pretty good pretty fast.
Errors were in the header supplied with clang itself. Looks like it can't handle MMX/SSE types properly. Try to add -msse -msse2 switches to the command line.
I'm using libstdc++ and built clang using VS2012Express for desktop. The cmake string was "Visual Studio 11 Win64" and the essential dirs. are specified using -I argument.
My guess you program could work if I used mingw headers for Windows.