mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
92c8a9439b
rust/mk/cfg/x86_64-pc-windows-msvc.mk

30 lines
1.4 KiB
Makefile
Raw Normal View History

Very hacky MSVC hacks. Conflicts: mk/platform.mk src/librustc/session/config.rs src/librustc_back/target/aarch64_apple_ios.rs src/librustc_back/target/aarch64_linux_android.rs src/librustc_back/target/arm_linux_androideabi.rs src/librustc_back/target/arm_unknown_linux_gnueabi.rs src/librustc_back/target/arm_unknown_linux_gnueabihf.rs src/librustc_back/target/armv7_apple_ios.rs src/librustc_back/target/armv7s_apple_ios.rs src/librustc_back/target/i386_apple_ios.rs src/librustc_back/target/i686_apple_darwin.rs src/librustc_back/target/i686_pc_windows_gnu.rs src/librustc_back/target/i686_unknown_dragonfly.rs src/librustc_back/target/i686_unknown_linux_gnu.rs src/librustc_back/target/mips_unknown_linux_gnu.rs src/librustc_back/target/mipsel_unknown_linux_gnu.rs src/librustc_back/target/mod.rs src/librustc_back/target/powerpc_unknown_linux_gnu.rs src/librustc_back/target/x86_64_apple_darwin.rs src/librustc_back/target/x86_64_apple_ios.rs src/librustc_back/target/x86_64_pc_windows_gnu.rs src/librustc_back/target/x86_64_unknown_dragonfly.rs src/librustc_back/target/x86_64_unknown_freebsd.rs src/librustc_back/target/x86_64_unknown_linux_gnu.rs src/librustc_back/target/x86_64_unknown_openbsd.rs src/librustc_llvm/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/trans/base.rs src/libstd/os.rs src/rustllvm/RustWrapper.cpp
2015-03-04 16:58:59 -06:00
# x86_64-pc-windows-msvc configuration
mk: Add support for i686-pc-windows-msvc This commit modifies the configure script and our makefiles to support building 32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can produce a 32-bit or 64-bit binary. The configure script was updated to export more variables at configure time, and the makefiles were rejiggered to selectively reexport the relevant environment variables for the applicable targets they're going to run for.
2015-06-25 17:30:00 -05:00
CC_x86_64-pc-windows-msvc="$(CFG_MSVC_CL_x86_64)" -nologo
LINK_x86_64-pc-windows-msvc="$(CFG_MSVC_LINK_x86_64)" -nologo
CXX_x86_64-pc-windows-msvc="$(CFG_MSVC_CL_x86_64)" -nologo
CPP_x86_64-pc-windows-msvc="$(CFG_MSVC_CL_x86_64)" -nologo
AR_x86_64-pc-windows-msvc="$(CFG_MSVC_LIB_x86_64)" -nologo
Very hacky MSVC hacks. Conflicts: mk/platform.mk src/librustc/session/config.rs src/librustc_back/target/aarch64_apple_ios.rs src/librustc_back/target/aarch64_linux_android.rs src/librustc_back/target/arm_linux_androideabi.rs src/librustc_back/target/arm_unknown_linux_gnueabi.rs src/librustc_back/target/arm_unknown_linux_gnueabihf.rs src/librustc_back/target/armv7_apple_ios.rs src/librustc_back/target/armv7s_apple_ios.rs src/librustc_back/target/i386_apple_ios.rs src/librustc_back/target/i686_apple_darwin.rs src/librustc_back/target/i686_pc_windows_gnu.rs src/librustc_back/target/i686_unknown_dragonfly.rs src/librustc_back/target/i686_unknown_linux_gnu.rs src/librustc_back/target/mips_unknown_linux_gnu.rs src/librustc_back/target/mipsel_unknown_linux_gnu.rs src/librustc_back/target/mod.rs src/librustc_back/target/powerpc_unknown_linux_gnu.rs src/librustc_back/target/x86_64_apple_darwin.rs src/librustc_back/target/x86_64_apple_ios.rs src/librustc_back/target/x86_64_pc_windows_gnu.rs src/librustc_back/target/x86_64_unknown_dragonfly.rs src/librustc_back/target/x86_64_unknown_freebsd.rs src/librustc_back/target/x86_64_unknown_linux_gnu.rs src/librustc_back/target/x86_64_unknown_openbsd.rs src/librustc_llvm/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/trans/base.rs src/libstd/os.rs src/rustllvm/RustWrapper.cpp
2015-03-04 16:58:59 -06:00
CFG_LIB_NAME_x86_64-pc-windows-msvc=$(1).dll
CFG_STATIC_LIB_NAME_x86_64-pc-windows-msvc=$(1).lib
mk: Tweak the LIB_GLOB for MSVC Right now the distribution tarball for MSVC only includes the *.dll files for the supporting libraries, but not the corresponding *.lib files which allow actually linking to the dll. This means that the current MSVC nightlies cannot produce dynamically linked binaries as the *.lib files are not available to link against. This commit modifies the `LIB_GLOB` used to copy the files around to include the `lib` variant of the `dll`.
2015-06-11 15:50:56 -05:00
CFG_LIB_GLOB_x86_64-pc-windows-msvc=$(1)-*.{dll,lib}
Very hacky MSVC hacks. Conflicts: mk/platform.mk src/librustc/session/config.rs src/librustc_back/target/aarch64_apple_ios.rs src/librustc_back/target/aarch64_linux_android.rs src/librustc_back/target/arm_linux_androideabi.rs src/librustc_back/target/arm_unknown_linux_gnueabi.rs src/librustc_back/target/arm_unknown_linux_gnueabihf.rs src/librustc_back/target/armv7_apple_ios.rs src/librustc_back/target/armv7s_apple_ios.rs src/librustc_back/target/i386_apple_ios.rs src/librustc_back/target/i686_apple_darwin.rs src/librustc_back/target/i686_pc_windows_gnu.rs src/librustc_back/target/i686_unknown_dragonfly.rs src/librustc_back/target/i686_unknown_linux_gnu.rs src/librustc_back/target/mips_unknown_linux_gnu.rs src/librustc_back/target/mipsel_unknown_linux_gnu.rs src/librustc_back/target/mod.rs src/librustc_back/target/powerpc_unknown_linux_gnu.rs src/librustc_back/target/x86_64_apple_darwin.rs src/librustc_back/target/x86_64_apple_ios.rs src/librustc_back/target/x86_64_pc_windows_gnu.rs src/librustc_back/target/x86_64_unknown_dragonfly.rs src/librustc_back/target/x86_64_unknown_freebsd.rs src/librustc_back/target/x86_64_unknown_linux_gnu.rs src/librustc_back/target/x86_64_unknown_openbsd.rs src/librustc_llvm/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/trans/base.rs src/libstd/os.rs src/rustllvm/RustWrapper.cpp
2015-03-04 16:58:59 -06:00
CFG_LIB_DSYM_GLOB_x86_64-pc-windows-msvc=$(1)-*.dylib.dSYM
Scale back changes made
2015-05-08 16:44:17 -05:00
CFG_JEMALLOC_CFLAGS_x86_64-pc-windows-msvc :=
mk: Compile C code on MSVC with /MD On MSVC there are two ways that the CRT can be linked, either statically or dynamically. Each object file produced by the compiler is compiled against msvcrt (a dll) or libcmt (a static library). When the linker is dealing with more than one object file, it requires that all object files link to the same CRT, or else the linker will spit out some errors. For now, compile code with `-MD` as it seems to appear more often in C libraries so we'll stick with the same trend.
2015-06-03 17:24:35 -05:00
CFG_GCCISH_CFLAGS_x86_64-pc-windows-msvc := -MD
CFG_GCCISH_CXXFLAGS_x86_64-pc-windows-msvc := -MD
Scale back changes made
2015-05-08 16:44:17 -05:00
CFG_GCCISH_LINK_FLAGS_x86_64-pc-windows-msvc :=
Very hacky MSVC hacks. Conflicts: mk/platform.mk src/librustc/session/config.rs src/librustc_back/target/aarch64_apple_ios.rs src/librustc_back/target/aarch64_linux_android.rs src/librustc_back/target/arm_linux_androideabi.rs src/librustc_back/target/arm_unknown_linux_gnueabi.rs src/librustc_back/target/arm_unknown_linux_gnueabihf.rs src/librustc_back/target/armv7_apple_ios.rs src/librustc_back/target/armv7s_apple_ios.rs src/librustc_back/target/i386_apple_ios.rs src/librustc_back/target/i686_apple_darwin.rs src/librustc_back/target/i686_pc_windows_gnu.rs src/librustc_back/target/i686_unknown_dragonfly.rs src/librustc_back/target/i686_unknown_linux_gnu.rs src/librustc_back/target/mips_unknown_linux_gnu.rs src/librustc_back/target/mipsel_unknown_linux_gnu.rs src/librustc_back/target/mod.rs src/librustc_back/target/powerpc_unknown_linux_gnu.rs src/librustc_back/target/x86_64_apple_darwin.rs src/librustc_back/target/x86_64_apple_ios.rs src/librustc_back/target/x86_64_pc_windows_gnu.rs src/librustc_back/target/x86_64_unknown_dragonfly.rs src/librustc_back/target/x86_64_unknown_freebsd.rs src/librustc_back/target/x86_64_unknown_linux_gnu.rs src/librustc_back/target/x86_64_unknown_openbsd.rs src/librustc_llvm/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/trans/base.rs src/libstd/os.rs src/rustllvm/RustWrapper.cpp
2015-03-04 16:58:59 -06:00
CFG_GCCISH_DEF_FLAG_x86_64-pc-windows-msvc :=
CFG_LLC_FLAGS_x86_64-pc-windows-msvc :=
CFG_INSTALL_NAME_x86_64-pc-windows-msvc =
CFG_EXE_SUFFIX_x86_64-pc-windows-msvc := .exe
CFG_WINDOWSY_x86_64-pc-windows-msvc := 1
CFG_UNIXY_x86_64-pc-windows-msvc :=
CFG_LDPATH_x86_64-pc-windows-msvc :=
CFG_RUN_x86_64-pc-windows-msvc=$(2)
CFG_RUN_TARG_x86_64-pc-windows-msvc=$(call CFG_RUN_x86_64-pc-windows-msvc,,$(2))
configure: Start adding MSVC support This commit starts to add MSVC support to the ./configure script to enable the build system to detect and build an MSVC target with the cl.exe compiler and toolchain. The primary change here is a large sanity check when an MSVC target is requested (and currently only `x86_64-pc-windows-msvc` is recognized). When building an MSVC target, the configure script either requires the `--msvc-root` argument or for `cl.exe` to be in `PATH`. It also requires that if in the path `cl.exe` is the 64-bit version of the compiler. Once detected the configure script will run the `vcvarsall.bat` script provided by Visual Studio to learn about the `INCLUDE` and `LIB` variables needed by the `cl.exe` compiler to run (the default include/lib paths for the compiler/linker). These variables are then reexported when running `make` to ensure that our own compiles are running the same toolchain. The purpose of this detection and environment variable scraping is to avoid requiring the build itself to be run inside of a `cmd.exe` shell but rather allow it to run in the currently expected MinGW/MSYS shell.
2015-05-11 15:59:51 -05:00
CFG_GNU_TRIPLE_x86_64-pc-windows-msvc := x86_64-pc-win32
mk: Fix MSVC bootstrapping itself Now that MSVC support has landed in the most recent nightlies we can now have MSVC bootstrap itself without going through a GNU compiler first. Unfortunately, however, the bootstrap currently fails due to the compiler not being able to find the llvm-ar.exe tool during the stage0 libcore compile. The compiler cannot find this tool because it's looking inside a directory that does not exist: $SYSROOT/rustlib/x86_64-pc-windows-gnu/bin The `gnu` on this triple is because the bootstrap compiler's host architecture is GNU. The build system, however, only arranges for the llvm-ar.exe tool to be available in this location: $SYSROOT/rustlib/x86_64-pc-windows-msvc/bin To resolve this discrepancy, the build system has been modified to understand triples that are bootstrapped from another triple, and in this case copy the native tools to the right location.
2015-05-27 19:30:57 -05:00
# All windows nightiles are currently a GNU triple, so this MSVC triple is not
# bootstrapping from itself. This is relevant during stage0, and other parts of
# the build system take this into account.
BOOTSTRAP_FROM_x86_64-pc-windows-msvc := x86_64-pc-windows-gnu
Reference in New Issue Copy Permalink