I am trying to install a simulation software on windows using MingW32 and cmake.
The problem I have is after I use :
cmake .. -DCMAKE_INSTALL_PREFIX="/cygdrive/c/Gromacs467" -DGMX_X11=OFF -DGMX_GPU=OFF -DGMX_MPI=OFF -DGMX_PREFER_STATIC_LIBS=ON -DGMX_CPU_ACCELERATION=SSE2 -DBUILD_SHARED_LIBS=NO -DGMX_BUILD_OWN_FFTW=ON -VMDDIR="C:\Program Files (x86)\University of Illinois\VMD" -G "MinGW Makefiles"
From a Microsoft visual studio, (Otherwise I ran in other issue).
I then start a MinGW console and go to the repertory where my Makefile was created, and enter the command make, and here is what I get :
c:\Temp\gromacs-4.6.7\cmake_build>make
Microsoft Windows [Version 10.0.10586]
(c) 2015 Microsoft Corporation. All rights reserved.
And naturally the make command does not actually execute. Why do I get the windows version ? No idea....
Interestingly enough, the name of the MniGW32 console change to add make at the end if I enter it more than once, and keeps on doing it later.
make --version gives the normal output, so I do not understand where the problem comes from.
c:\Temp\gromacs-4.6.7\cmake_build>make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i686-pc-msys
If you use cmake ... -G "MinGW Makefiles" you will need to call mingw32-make.
And just a hint: I assume you were previously building with Cygwin and for MinGW32 it should be -DCMAKE_INSTALL_PREFIX="/c/Gromacs467" instead of -DCMAKE_INSTALL_PREFIX="/cygdrive/c/Gromacs467"
References
CMake Error at CMakeLists.txt:30 (project): No CMAKE_C_COMPILER could be found
How to compile makefile using MinGW?
Instead of calling make directly, you can let CMake invoke the build for you with the following syntax:
cmake --build <build-dir> --target <target-name> --config <build-type>
The --target and --config arguments are optional and <build-dir> must point to your CMake project's build directory. The main advantage to invoking your build this way is that CMake has already determined the build tool and knows where to find it and how to invoke it correctly. Invoking your build via CMake in this manner is likely to be more robust.
Basic CMake documentation for the --build option available here and some related material can be found in this blog post, particularly the section "Abstracting away the build tool" (disclosure: I wrote the blog article).
Related
Following this post, I'm trying to compile Elmer FEM on Windows using the MinGW compilers. However when running the
cmake -DCMAKE_C_COMPILER=C:\\MinGW\\bin\\gcc.exe -DCMAKE_CXX_COMPILER=C:\\MinGW\\bin\\g++.exe -DCMAKE_Fortran_COMPILER=C:\\MinGW\\bin\\gfortran.exe ..
command in the build folder I get the error:
-- Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.18363.
-- The Fortran compiler identification is unknown
-- Check for working Fortran compiler: C:\MinGW\bin\gfortran.exe
-- Check for working Fortran compiler: C:\MinGW\bin\gfortran.exe -- broken
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/CMakeTestFortranCompiler.cmake:45 (message):
The Fortran compiler
"C:\MinGW\bin\gfortran.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/foobar/Desktop/elmer/elmerfem/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/Common7/IDE/devenv.com CMAKE_TRY_COMPILE.sln /build Debug /project cmTC_8d573 &&
Microsoft Visual Studio 2017 Version 15.0.28010.2050.
Copyright (C) Microsoft Corp. All rights reserved.
Some errors occurred during migration. For more information, see the migration report:
C:\Users\foobar\Desktop\elmer\elmerfem\build\CMakeFiles\CMakeTmp\UpgradeLog.htm
Invalid project
from here I tried adding the
set(CMAKE_TRY_COMPILE_TARGET_TYPE "STATIC_LIBRARY")
to the CmakeLists.txt file, running the cmd as admin from here, and from here tried uninstalling (from Chocolatey) and re-installing MinGW from the original website with no avail. I would appreciate it if you could help me know what is the problem and how I can solve it.
P.S. To solve the above issue one shoudl use the command:
cmake -DCMAKE_C_COMPILER=C:/MinGW/bin/gcc.exe -DCMAKE_CXX_COMPILER=C:/MinGW/bin/g++.exe -DCMAKE_Fortran_COMPILER=C:/MinGW/bin/gfortran.exe -DCMAKE_MAKE_PROGRAM=C:/MinGW/bin/mingw32-make.exe .. -G "MinGW Makefiles"
But then there is the missing BLAS issue. I'm trying to solve. this using MSYS2
To build Elmer on Windows, you need MSYS as you pointed out (the Visual Studio error about an invalid project is because an Intel Fortran Visual Studio project was generated when running in cmd.exe but the Intel Fortran Visual Studio extension is not installed). Use pacman to install Elmer's MSYS dependencies: cmake, openblas, qt5, qwt-qt5, and nsis (as of commit 442ea2000f87). See this script for all the commands required to install these dependencies. You can also run that script in MSYS to install all the required dependencies, build Elmer, and create a local Elmer install directory with executable Elmer binaries.
I've been trying to code something using the new experimental feature "modules-ts" that will be included in c++20. I've cloned the gcc branch (found here: https://gcc.gnu.org/wiki/cxx-modules), and I'm trying to follow that tutorial (on the link) using modules-ts but an g++ error is preventing me from doing that:
g++: error: unrecognized command-line option ‘-fmodules-ts’
I tried to see the version of g++, to make sure that is not reading from another previous version. And the answer is:
g++ (GCC) 10.0.0 20191029 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Here is the command that I'm trying to run:
g++ -fmodules-ts hello.cppm main.cpp
Modules-ts is not merged into GCC's main branch yet. You need to download GCC's source and compile it yourself, for further instructions see GCC's installation guide. Grab the source using
svn co svn://gcc.gnu.org/svn/gcc/branches/c++-modules SomeLocalDir
instead of
svn checkout svn://gcc.gnu.org/svn/gcc/trunk SomeLocalDir
and you'll get the correct version.
EDIT:
For clarification, in this answer I assumed the OP did not compile the right GCC version because there is no svn revision number inside his gcc --version.
To distribute a Qt appication to Windows users as a simple .exe file, one would need to link statically with a static version of Qt libraries. Assume we distribute our license under an open license so that static linking of Qt is allowed. So we just need static library binaries of Qt5Core, Qt5Gui, Qt5Widgets. How to get them?
The binary distribution of Qt5 comes with dynamic libraries only. It contains some .lib files as well - but beware, these are not the static libraries, but some auxiliary files. They can be distinguished from true static libraries by their size: true static libraries are much bigger (many MB in the case of Qt5 components). So we need to statically compile Qt5 ourselves. This turns out to be surprisingly difficult.
The official instructions (http://doc.qt.io/qt-5/windows-building.html) are almost useless: Way too short, they do not even convey an idea of the difficulty of the task. A precise, up-to-date, step-by-step guide how to compile Qt5 into static libraries is currently missing. We should have it here.
The short answer: Don't waste your time on this. Link dynamically, and let an installer distribute your application. This is the only mode that is seriously supported by Qt5 and by CMake. Working without their support and against their advise is close to hopeless. Setting up an installer is far easier (though no fun either - we currenly use black magic from https://hk.saowen.com/a/d1cf90fcfea6d511629fd5a6c8113808721a7f19656677e8a5fab370a8d35cd4).
The long (yet incomplete) answer, in case you want to outsmart me:
The following steps brought me deceptively close to a solution. I succeeded in building static libraries, but I failed to link my application: Upon getting hundreds of LNK2001 and LNK2019 errors caused by cryptic unresolved external symbols, I had to give up.
So here comes a step-by-step description of what worked for me in October 2018 on a Windows10 virtual desktop. For each installation step, a check is indicated. If a check fails then fix the problem before proceeding further.
To start, install some tools that are needed later on:
Perl, needed for zlib and openssl configuration:
Skip if "perl -v" works.
Get installer from https://www.activestate.com/activeperl
Run installer -> will install to C:\Perl64.
Check: Restart terminal and try "perl -v".
An editor that can handle Unix end-of-line. Notepad won't do. Install vim, emacs, or whatsoever.
chocolatey package manager, needed to install flex and bison:
Run admin shell (Circle Menu > search for "Command" > right-click on "Command Prompt" > run as Admin)
Copy download command from https://chocolatey.org/install#install-with-cmdexe
Paste command to admin shell, and watch installation
Check: in terminal, try command "choco"
flex and bison, needed by qtbase compilation:
It's not obvious to get the right version of flex. From gnuwin32.sourceforge.net I got an outdated flex that missed a command-line argument required during Qt compilation. Compiling flex from source introduces a tail of further dependences. The simplest solution I found uses the Chocolatey package manager.
In admin shell, run: "choco install winflexbison3". This creates a directory X that contains the binaries win_flex.exe and win_bison.exe and a supporting "data" folder. Find out the location of X. In my case, X=C:\ProgramData\chocolatey\lib\winflexbison3\tools
Check: cd X, and run "win_flex --version", "win_bison --version".
During Qt compilation, these tools will be needed under their standard names "flex" and "bison". Therefore we need symbolic links flex->win_flex, bison->win_bison.
mlink X\flex.exe X\win_flex.exe
mlink X\bison.exe X\win_bison.exe
note: mklink needs absolute paths to work reliably
note: the symlink must not go to another directory lest bison won't find the "data" folder
Add X to the %PATH%
Check: in any shell, try "flex --version" and "bison --version"
So far for the tools. Now we need two libraries that must be statically linked to Qt (magic learned from https://stackoverflow.com/a/41815812/1017348):
Build static zlib:
Download https://zlib.net/zlib1211.zip
Unpack to C:\Development\zlib-1.2.11
Edit the file win32\Makefile.msc with an editor that can handle Unix EOLs:
Find the line starting with CFLAGS
Replace -MD with -GL -MT -Zc:wchar_t-
Find the line starting with LDFLAGS
Replace -debug with -opt:icf -dynamicbase -nxcompat -ltcg /nodefaultlib:msvcrt
Build zlib using the following command (should take less than a minute):
nmake -f win32/Makefile.msc AS=ml64 LOC="-DASMV -DASMINF -DNDEBUG -I." OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
Check: as a result, the source directory must contain zlib.lib (856kB), inter alia.
Build static openssl library:
Download https://www.openssl.org/source/openssl-1.1.1.tar.gz
Unpack to C:\Development\openssl-1.1.1
Copy files from zlib: cd zlib-1.2.11; xcopy zconf.h ..\openssl-1.1.1\ ; same for zlib.h zlib.lib zlib.pdb
cd ..\openssl-1.1.1
perl Configure VC-WIN64A no-asm no-shared zlib no-zlib-dynamic threads --prefix=C:\opt\local_x64
note: I added "no-asm" to avoid installation of NASM (Netwide Assembler)
note: I changed prefix, since only admins can install to C:\Windows
Edits the file ''makefile'':
Find the line that starts with: CFLAG
Append: /Zc:wchar_t- /GL /Zi
Find the line that starts with: LDFLAGS
Replace /debug with /incremental:no /opt:icf /dynamicbase /nxcompat /ltcg /nodefaultlib:msvcrt
Find the line that starts with: CNF_EX_LIBS
Replace ZLIB1 with zlib.lib
Build: "nmake"
Check: directory must contain openssl.lib (size?)
Now we are ready to build qtbase from source, using the command-line version of the Visual Studio C++ compiler:
Download (update location for latest Qt): https://download.qt.io/archive/qt/5.11/5.11.2/submodules/qtbase-everywhere-src-5.11.2.zip
Unpacking takes ca 20'
Move the source directory to the Local Disk (C:\Development)
To work with Visual Studio, use a specially configured terminal. Use Taskbar>Circle>Search to launch "x64 Native Tools Command Prompt for VS 2017"
cd qtbase...
Check: configure --help
configure -platform win32-msvc2017 -opensource -confirm-license -release -static -openssl-linked no-dbus -no-libpng -no-libjpeg -nomake examples -nomake tests -prefix C:\opt\local_x64 -I C:\Development\openssl-1.1.1\include -L C:\Development\openssl-1.1.1 -D OPENSSL_LIBS=C:\Development\openssl-1.1.1\libssl.lib
while debugging "configure", it may be necessary to delete config.cache.
option -I does not work with relative paths
the label "win32" may look wrong if we want to use Qt in a 64bit application, but we are advised not to worry: building Qt under Windows: really with "-platform win32-msvc2017"?
I don't know how to get rid of Sql: https://bugreports.qt.io/browse/QTBUG-71253
libpng and libjpeg are needed by optional code. They are provided in src/3rdparty, which tends to provoke clashes with system provided library versions. Therefore, we build without PNG and JPG support.
nmake
Check: static libraries (big .lib and small .prl) land in directory lib/
54.7 MB Qt5Core.lib
23.4 MB Qt5Widgets.lib
18.2 MB Qt5Gui.lib
07.4 MB Qt5Network.lib
...
That's it, we have static Qt libraries. Only, as said above, this did not help me when I tried to link my application with these libraries.
I installed Rust on a Windows 10 machine with rustup-init.exe - the method recommended in the Rust Book. The installer told me that Rust needs C-runtime of VS2013 or newer. I have VS2017 installed, I assumed Rust doesn't support VS2017 yet and so agreed to install C-runtime. Installation finished successfully.
main.rs:
fn main() {
println!("Hello, world!");
}
Compiling:
> rustc main.rs
error: linking with `link.exe` failed: exit code: 1
|
= note: "link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "main.0.o" "/OUT:main.exe" "/OPT:REF,NOICF" "/DEBUG" "/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-0a78323911070f99.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librand-c279a51d66700350.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcollections-d7bf31a4ca1ea637.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd_unicode-d367c3ba0db49600.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-2d4bf02140c11dcb.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-add7a84d7e82d084.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liblibc-84688accbc86d6b7.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-fe2e68b21f0bdd7a.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc_system-7fc0381594c93f56.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-ea9d77e7c23fe65c.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-91b619d34dd1f5aa.rlib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "shell32.lib" "msvcrt.lib"
= note: /usr/bin/link: extra operand '/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib'
Try '/usr/bin/link --help' for more information.
error: aborting due to previous error
link.exe LIBPATH arg is specified twice.
What's going on?
> rustc --version
rustc 1.17.0 (56124baa9 2017-04-24)
As the rustup documentation says:
As mentioned on the Rust download page, there are two ABIs in use on Windows: the native (MSVC) ABI used by Visual Studio, and the GNU ABI used by the GCC toolchain. Which version of Rust you need depends largely on what C/C++ libraries you want to interoperate with: for interop with software produced by Visual Studio use the MSVC build of Rust; for interop with GNU software built using the MinGW/MSYS2 toolchain use the GNU build.
You have installed the MSVC toolchain. However, you are running the the compiler in a command shell where link.exe does not point to the MSVC linker, but instead to a GNU toolchain — MSVC does not call its linker /usr/bin/link or use options like --help!
You should configure your shell so the MSVC linker is foremost in the PATH or switch to the GNU ABI if that's your goal.
Compare the help output of the two:
$ link --help
Usage: link FILE1 FILE2
or: link OPTION
Call the link function to create a link named FILE2 to an existing FILE1.
--help display this help and exit
--version output version information and exit
GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
Full documentation at: <http://www.gnu.org/software/coreutils/link>
or available locally via: info '(coreutils) link invocation'
> link /help
Microsoft (R) Incremental Linker Version 14.10.25017.0
Copyright (C) Microsoft Corporation. All rights reserved.
For help on Linker, type `link /link' or `link'
For help on Library Manager, type `link /lib' or `lib'
For help on Dumper, type `link /dump' or `dumpbin'
For help on Editor, type `link /edit' or `editbin'
For help on CvtCIL, type `link /cvtcil'
I assumed Rust doesn't support VS2017 yet
It supports VS2017 just fine; as described in the 1.17 release notes, the problem is that it cannot automatically find the MSVC installation due to changes in where MSVC installs. Running the Rust compiler from inside a shell that has the proper environment works fine.
I'm trying to build LLVM/Clang on Windows 7 with Microsoft C++ 2013. Building LLVM spat out a few error messages along the way but mostly seemed to be succeeding and did end up creating a folder full of exe's so that part seems to have worked. When I try to build Clang:
C:\clang>\CMake\bin\cmake.exe ..\clang-3.4 -DCLANG_PATH_TO_LLVM_BUILD=/llvm
CMake Error at CMakeLists.txt:29 (message):
Please set CLANG_PATH_TO_LLVM_BUILD to a directory containing a LLVM build.
And I get the same error message whether I omit CLANG_PATH_TO_LLVM_BUILD, define it in CMakeLists.txt or an environment variable instead of the command line, set it to possibly relevant subdirectories of /llvm etc.
What am I missing?
You're not following the instructions on this page correctly, under "Using Visual Studio". You will end up with
/
/llvm
/llvm/CMakeLists.txt
/llvm/tools/clang
/llvm/tools/clang/CMakeLists.txt
Step 4, repeated here for clarity:
Run CMake to generate the Visual Studio solution and project files:
cd ..\.. (back to where you started)
mkdir build (for building without polluting the source dir)
cd build
If you are using Visual Studio 2012: cmake -G "Visual Studio 11" ..\llvm
That last bit needs to be run from inside the VS Command Prompt, but you seem to have that sorted out. You can also generate "NMake makefiles" if you don't use the IDE to build. Anyways, the point is that you should call cmake on the toplevel CMakeLists.txt file, not on the clang one directly. Clang will be built as part of the build process. You can even add libc++ and compiler-rt to the llvm/projects directory to have these built automatically on platforms that support them.
What you are doing is building clang "out of tree". Which is possible and even supported, but only really useful in certain circumstances. You'll need a previously built build of LLVM in some directory. You then set CLANG_PATH_TO_LLVM_BUILD to the directory containing the built LLVM files (this is not the source directory). But as I said, that's making things needlessly difficult.