I want to build exe file on windows,
without need of vcruntime.
So I tried:
.cargo/config
[target.i686-pc-windows-msvc]
rustflags = ["-Clink-args=/MT"]
looks like cargo found config, because of cargo rebuild
whole project, but dumpbin /DEPENDENTS test.exe
still show VCRUNTIME140.dll as dependencies,
any ideas how link VCRUNTIME140 statically?
See this rfc
You can try it with rustc nightly:
c:\Users\IEUser\test2>rustc -Z unstable-options -C target-feature=+crt-static test.rs
user1034749 answer pertains to rustc. If you want to do this with cargo, the info is here: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
RUSTFLAGS='-C target-feature=+crt-static' cargo build --target x86_64-pc-windows-msvc
Related
How do I deploy boost for arm64 to a GitHub Actions Runner Image under macOS?
I am using Github Actions to build my project, which depends on boost.
As far as I can tell, when I set the YAML label to macos-11, the runner image itself is intel.
For my x86_64 build, I simply say
brew install boost
And the job can then go on to compile and link my own code successfully.
If I understand correctly, it is not possible to use brew to install boost arm64 binaries to a macOS intel machine.
Maybe I could build boost from source using something like
./bootstrap.sh
./b2 install
What flags would I pass to tell it to cross compile the arm64 binaries?
Edit: I found the solution and posted the answer below, stack overflow tells me that I do not have enough karma to mark my own answer as accepted.
At the bottom of this page...
B2 4.7.1 MacOS Armv8 package bundles x86_64 binary
...it says:
./b2 architecture=arm address-model=64 -s NO_LZMA=1 -s NO_ZSTD=1 abi=aapcs
That worked for me. The entire step that I have on github actions is:
- name: Boost
run: |
curl -O -L https://boostorg.jfrog.io/artifactory/main/release/1.80.0/source/boost_1_80_0.tar.gz
tar xfz boost_1_80_0.tar.gz
cd boost_1_80_0
./bootstrap.sh
./b2 architecture=arm address-model=64 -s NO_LZMA=1 -s NO_ZSTD=1 abi=aapcs install
lipo /usr/local/lib/libboost_*.dylib -info
I tried using a demo to compile tbb in my project.
Link of the demo https://www.selectiveintellect.net/blog/2016/7/29/using-cmake-to-add-third-party-libraries-to-your-project-1
IDE for me is VS2013 and get an error about command 'make'
Performing build step for 'tbb44'
2> CMake Error at F:/CPPs/FAsT-Match-master/build/tbb44/src/tbb44-stamp/tbb44-build-Debug.cmake:49 (message):
2> Command failed: 2
2>
2> 'make' 'tbb_build_prefix=tbb44'
The original command is generated via tbb.cmake, for which it looks like
ExternalProject_Add(${TBB_PREFIX}
PREFIX ${TBB_PREFIX}
URL ${TBB_URL}
URL_MD5 ${TBB_URL_MD5}
CONFIGURE_COMMAND ""
# BUILD_COMMAND ${TBB_MAKE} -j${NCPU} tbb_build_prefix=${TBB_PREFIX}
BUILD_COMMAND ${TBB_MAKE} tbb_build_prefix=${TBB_PREFIX}
The one commented is the original and the one behind is modified.
Is this the problem of MSVC?
That blog post is just completely wrong. TBB comes with its own CMake build now, so there's absolutely no reason to go through ExternalProject like this.
Here's how I built it from source, using Visual Studio 2019 (the instructions should be pretty much the same). From a developer command prompt, using CMake 3.20:
D:\>git clone https://github.com/oneapi-src/oneTBB
D:\>cmake -S oneTBB -B oneTBB-build -DTBB_TEST=OFF
D:\>cmake --build oneTBB-build --config Release
D:\>cmake --build oneTBB-build --config Debug
D:\>cmake --install oneTBB-build --prefix oneTBB-install --config Release
D:\>cmake --install oneTBB-build --prefix oneTBB-install --config Debug
Setting TBB_TEST to OFF saves a lot of time waiting on TBB's tests to build. These commands install the Debug and Release binaries to D:\oneTBB-install. Of course, you can place this folder anywhere you like.
Once this is done, you may use your new TBB build from your project like so:
cmake_minimum_required(VERSION 3.20)
project(TBB-test)
find_package(TBB REQUIRED)
add_executable(main main.cpp)
target_link_libraries(main PRIVATE TBB::tbb)
The TBB package also includes libraries TBB::tbbmalloc and TBB::tbbmalloc_proxy.
When you build your project, you may point find_package to your TBB installation by setting the CMake variable TBB_ROOT to D:/oneTBB-install at the command line via:
D:\>cmake -S myProject -B myProject-build -DTBB_ROOT=D:/oneTBB-install
I have written a program in Rust on my M1 Mac, and compiled it to a Unix executable just fine. Now I want to compile it to a Windows executable as well. I first tried
$ cargo target add x86_64-pc-windows-gnu
$ cargo build --release --target=x86_64-pc-windows-gnu
I got the error message:
error: linker x86_64-w64-mingw32-gcc not found
so I tried
$ brew install mingw-w64
according to this, and got the error:
Error: mingw-w64: no bottle available!
I looked on formulae.brew.sh and it seems that mingw-w64 isn't supported for M1, only Intel.
How can I compile an exe from rust using my M1 Mac?
Solution 1:
You can install/add the targets using these commands :
rustup target add x86_64-pc-windows-gnu
rustup toolchain install stable-x86_64-pc-windows-gnu
then you can target windows from your mac:
cargo build --release --target=x86_64-pc-windows-gnu
Solution 2:
Simply use docker!
FROM mcr.microsoft.com/windows/servercore:ltsc2019
// install rust
COPY project c:/project
RUN cd c:/project && cargo build --release
Solution 3:
there is also Cross. you can use this for cross-compilation:
https://github.com/rust-embedded/cross
I'm going to jump in with a couple newer solutions that worked really well for me:
cargo-zigbuild
Targets (*-pc-windows-gnu afaik):
i686-pc-windows-gnu
x86_64-pc-windows-gnu
cargo-zigbuild also supports cross-compiling to other platforms out of the box as well, with no containerization needed!
Quick example:
brew install zig
cargo install cargo-zigbuild
cargo zigbuild --target x86_64-pc-windows-gnu -r
cargo-xwin
Targets (*-msvc afaik):
aarch64-pc-windows-msvc
i586-pc-windows-msvc
i686-pc-windows-msvc
x86_64-pc-windows-msvc
Quick example:
cargo install cargo-xwin
cargo xwin build --target x86_64-pc-windows-msvc -r
Which one do I pick?
See: Difference between the gnu and msvc toolchains?
TL;DR: Use msvc/cargo-xwin for "more native" windows binaries (that are smaller in size) & use gnu/cargo-zigbuild to help porting over a linux-specific application.
I'm trying to compile a C program using Ncurses on Windows. I compiled it successfully using GCC and it works perfectly if I run it in Cygwin or MSYS2. However, if I try to run it in the Windows Command Prompt, I get this error:
Error opening terminal: xterm-256color.
Is it possible to compile it to run using the native Windows console? This is how I've been compiling it:
gcc -o PROGRAMNAME main.c -lncurses
I also have the Cygwin and Msys dlls for Ncurses copied into the directory of the compiled executable.
Update
So I figured out how to get the program to run. I deleted all the DLLs from the project folder and then added "C:\msys64\usr\bin" to my PATH environment variable. However, I would still like to know if there's a way to get this to work if I were to distribute it, since it's still relying on my installation of MSYS2.
Update 2
Gave up and just used pdcurses and it works fine.
Update 3
Nevermind, found a solution! See below.
I figured out a solution. I'll post it here in case anyone else has this same issue. Thanks to Thomas Dickey for your help!
Install the mingw-w64 toolchain and any other packages you need to compile your project (this is mostly where I messed up)
Make sure to include the /mingw64/include/ncurses directory when compiling, or else gcc won't be able to find curses.h
Include /mingw64/bin as a static directory or copy over the necessary dlls to the same folder as the directory
I ended up with this to compile:
gcc -I/mingw64/include/ncurses -o PROGRAMNAME main.c -lncurses -L/mingw64/bin -static
Is there a way to configure CLion to use a local makefile to compile code, rather than CMake? I can't seem to find the way to do it from the build options.
Update: If you are using CLion 2020.2, then it already supports Makefiles. If you are using an older version, read on.
Even though currently only CMake is supported, you can instruct CMake to call make with your custom Makefile. Edit your CMakeLists.txt adding one of these two commands:
add_custom_target
add_custom_command
When you tell CLion to run your program, it will try to find an executable with the same name of the target in the directory pointed by PROJECT_BINARY_DIR. So as long as your make generates the file where CLion expects, there will be no problem.
Here is a working example:
Tell CLion to pass its $(PROJECT_BINARY_DIR) to make
This is the sample CMakeLists.txt:
cmake_minimum_required(VERSION 2.8.4)
project(mytest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_custom_target(mytest COMMAND make -C ${mytest_SOURCE_DIR}
CLION_EXE_DIR=${PROJECT_BINARY_DIR})
Tell make to generate the executable in CLion's directory
This is the sample Makefile:
all:
echo Compiling $(CLION_EXE_DIR)/$# ...
g++ mytest.cpp -o $(CLION_EXE_DIR)/mytest
That is all, you may also want to change your program's working directory so it executes as it is when you run make from inside your directory. For this edit: Run -> Edit Configurations ... -> mytest -> Working directory
While this is one of the most voted feature requests, there is one plugin available, by Victor Kropp, that adds support to makefiles:
Makefile support plugin for IntelliJ IDEA
Install
You can install directly from the official repository:
Settings > Plugins > search for makefile > Search in repositories > Install > Restart
Use
There are at least three different ways to run:
Right click on a makefile and select Run
Have the makefile open in the editor, put the cursor over one target (anywhere on the line), hit alt + enter, then select make target
Hit ctrl/cmd + shift + F10 on a target (although this one didn't work for me on a mac).
It opens a pane named Run target with the output.
Newest version has better support literally for any generated Makefiles, through the compiledb
Three steps:
install compiledb
pip install compiledb
run a dry make
compiledb -n make
(do the autogen, configure if needed)
there will be a compile_commands.json file generated
open the project and you will see CLion will load info from the json file.
If you your CLion still try to find CMakeLists.txt and cannot read compile_commands.json, try to remove the entire folder, re-download the source files, and redo step 1,2,3
Orignal post: Working with Makefiles in CLion using Compilation DB
To totally avoid using CMAKE, you can simply:
Build your project as you normally with Make through the terminal.
Change your CLion configurations, go to (in top bar) :
Run -> Edit Configurations -> yourProjectFolder
Change the Executable to the one generated with Make
Change the Working directory to the folder holding your executable (if needed)
Remove the Build task in the Before launch:Activate tool window box
And you're all set! You can now use the debug button after your manual build.
Currently, only CMake is supported by CLion. Others build systems will be added in the future, but currently, you can only use CMake.
An importer tool has been implemented to help you to use CMake.
Edit:
Source : http://blog.jetbrains.com/clion/2014/09/clion-answers-frequently-asked-questions/
I am not very familiar with CMake and could not use Mondkin's solution directly.
Here is what I came up with in my CMakeLists.txt using the latest version of CLion (1.2.4) and MinGW on Windows (I guess you will just need to replace all:
g++ mytest.cpp -o bin/mytest by make if you are not using the same setup):
cmake_minimum_required(VERSION 3.3)
project(mytest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_custom_target(mytest ALL COMMAND mingw32-make WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
And the custom Makefile is like this (it is located at the root of my project and generates the executable in a bin directory):
all:
g++ mytest.cpp -o bin/mytest
I am able to build the executable and errors in the log window are clickable.
Hints in the IDE are quite limited through, which is a big limitation compared to pure CMake projects...