Rust library for build scripts to compile C/C++ code into a Rust library

Overview

cc-rs

A library to compile C/C++/assembly into a Rust library/application.

Documentation

A simple library meant to be used as a build dependency with Cargo packages in order to build a set of C/C++ files into a static archive. This crate calls out to the most relevant compiler for a platform, for example using cl on MSVC.

Using cc-rs

First, you'll want to both add a build script for your crate (build.rs) and also add this crate to your Cargo.toml via:

[build-dependencies]
cc = "1.0"

Next up, you'll want to write a build script like so:

// build.rs

fn main() {
    cc::Build::new()
        .file("foo.c")
        .file("bar.c")
        .compile("foo");
}

And that's it! Running cargo build should take care of the rest and your Rust application will now have the C files foo.c and bar.c compiled into a file named libfoo.a. If the C files contain

void foo_function(void) { ... }

and

int32_t bar_function(int32_t x) { ... }

you can call them from Rust by declaring them in your Rust code like so:

extern {
    fn foo_function();
    fn bar_function(x: i32) -> i32;
}

pub fn call() {
    unsafe {
        foo_function();
        bar_function(42);
    }
}

fn main() {
    // ...
}

See the Rustonomicon for more details.

External configuration via environment variables

To control the programs and flags used for building, the builder can set a number of different environment variables.

  • CFLAGS - a series of space separated flags passed to compilers. Note that individual flags cannot currently contain spaces, so doing something like: -L=foo\ bar is not possible.
  • CC - the actual C compiler used. Note that this is used as an exact executable name, so (for example) no extra flags can be passed inside this variable, and the builder must ensure that there aren't any trailing spaces. This compiler must understand the -c flag. For certain TARGETs, it also is assumed to know about other flags (most common is -fPIC).
  • AR - the ar (archiver) executable to use to build the static library.
  • CRATE_CC_NO_DEFAULTS - the default compiler flags may cause conflicts in some cross compiling scenarios. Setting this variable will disable the generation of default compiler flags.
  • CXX... - see C++ Support.

Each of these variables can also be supplied with certain prefixes and suffixes, in the following prioritized order:

  1. _ - for example, CC_x86_64-unknown-linux-gnu
  2. _ - for example, CC_x86_64_unknown_linux_gnu
  3. _ - for example, HOST_CC or TARGET_CFLAGS
  4. - a plain CC, AR as above.

If none of these variables exist, cc-rs uses built-in defaults

In addition to the above optional environment variables, cc-rs has some functions with hard requirements on some variables supplied by cargo's build-script driver that it has the TARGET, OUT_DIR, OPT_LEVEL, and HOST variables.

Optional features

Parallel

Currently cc-rs supports parallel compilation (think make -jN) but this feature is turned off by default. To enable cc-rs to compile C/C++ in parallel, you can change your dependency to:

[build-dependencies]
cc = { version = "1.0", features = ["parallel"] }

By default cc-rs will limit parallelism to $NUM_JOBS, or if not present it will limit it to the number of cpus on the machine. If you are using cargo, use -jN option of build, test and run commands as $NUM_JOBS is supplied by cargo.

Compile-time Requirements

To work properly this crate needs access to a C compiler when the build script is being run. This crate does not ship a C compiler with it. The compiler required varies per platform, but there are three broad categories:

  • Unix platforms require cc to be the C compiler. This can be found by installing cc/clang on Linux distributions and Xcode on macOS, for example.
  • Windows platforms targeting MSVC (e.g. your target triple ends in -msvc) require cl.exe to be available and in PATH. This is typically found in standard Visual Studio installations and the PATH can be set up by running the appropriate developer tools shell.
  • Windows platforms targeting MinGW (e.g. your target triple ends in -gnu) require cc to be available in PATH. We recommend the MinGW-w64 distribution, which is using the Win-builds installation system. You may also acquire it via MSYS2, as explained here. Make sure to install the appropriate architecture corresponding to your installation of rustc. GCC from older MinGW project is compatible only with 32-bit rust compiler.

C++ support

cc-rs supports C++ libraries compilation by using the cpp method on Build:

fn main() {
    cc::Build::new()
        .cpp(true) // Switch to C++ library compilation.
        .file("foo.cpp")
        .compile("libfoo.a");
}

For C++ libraries, the CXX and CXXFLAGS environment variables are used instead of CC and CFLAGS.

The C++ standard library may be linked to the crate target. By default it's libc++ for macOS, FreeBSD, and OpenBSD, libc++_shared for Android, nothing for MSVC, and libstdc++ for anything else. It can be changed in one of two ways:

  1. by using the cpp_link_stdlib method on Build:
    fn main() {
        cc::Build::new()
            .cpp(true)
            .file("foo.cpp")
            .cpp_link_stdlib("stdc++") // use libstdc++
            .compile("libfoo.a");
    }
  2. by setting the CXXSTDLIB environment variable.

In particular, for Android you may want to use c++_static if you have at most one shared library.

Remember that C++ does name mangling so extern "C" might be required to enable Rust linker to find your functions.

CUDA C++ support

cc-rs also supports compiling CUDA C++ libraries by using the cuda method on Build (currently for GNU/Clang toolchains only):

fn main() {
    cc::Build::new()
        // Switch to CUDA C++ library compilation using NVCC.
        .cuda(true)
        .cudart("static")
        // Generate code for Maxwell (GTX 970, 980, 980 Ti, Titan X).
        .flag("-gencode").flag("arch=compute_52,code=sm_52")
        // Generate code for Maxwell (Jetson TX1).
        .flag("-gencode").flag("arch=compute_53,code=sm_53")
        // Generate code for Pascal (GTX 1070, 1080, 1080 Ti, Titan Xp).
        .flag("-gencode").flag("arch=compute_61,code=sm_61")
        // Generate code for Pascal (Tesla P100).
        .flag("-gencode").flag("arch=compute_60,code=sm_60")
        // Generate code for Pascal (Jetson TX2).
        .flag("-gencode").flag("arch=compute_62,code=sm_62")
        .file("bar.cu")
        .compile("libbar.a");
}

License

This project is licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in cc-rs by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Comments
  • Emscripten: emcc not found on win32 cross-compile

    Emscripten: emcc not found on win32 cross-compile

    Saw this on Nightly a few months back and just thought it was a stability issue but looks like with the recent 1.20 release it's made it into stable:

    (note some portion of the paths are sanitized with 'zzz')

    error: failed to run custom build command for `lua v0.0.11 (file:///C:/zzz/rust-lua53)`
    process didn't exit successfully: `C:\zzz\target\release\build\lua-91f996492c3978b1\build-script-build` (exit code: 101)
    --- stdout
    TARGET = Some("asmjs-unknown-emscripten")
    OPT_LEVEL = Some("3")
    TARGET = Some("asmjs-unknown-emscripten")
    HOST = Some("x86_64-pc-windows-msvc")
    TARGET = Some("asmjs-unknown-emscripten")
    TARGET = Some("asmjs-unknown-emscripten")
    HOST = Some("x86_64-pc-windows-msvc")
    CC_asmjs-unknown-emscripten = None
    CC_asmjs_unknown_emscripten = None
    TARGET_CC = None
    CC = None
    TARGET = Some("asmjs-unknown-emscripten")
    HOST = Some("x86_64-pc-windows-msvc")
    CFLAGS_asmjs-unknown-emscripten = None
    CFLAGS_asmjs_unknown_emscripten = None
    TARGET_CFLAGS = None
    CFLAGS = None
    PROFILE = Some("release")
    running: "emcc.bat" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-DLUA_32BITS" "-DLUA_COMPAT_LOADSTRING" "-o" "C:\\zzz\target\\asmjs-unknown-emscripten\\release\\build\\lua-7f6f6329781534a1\\out\\lua-source\\src\\lapi.o" "-c" "lua-source\\src\\lapi.c"
    cargo:warning=python: can't open file 'C:\zzz\rust-lua53\\emcc': [Errno 2] No such file or directory
    exit code: 2
    

    When I was debugging this before the issue came down to how Command was now pulling in certain environment variables.

    Specifically the way emcc is invoked through emcc.bat on windows:

    @echo off
    python "%~dp0\emcc" %*
    

    Here "%~dp0" is supposed to be the folder of where emcc.bat exists, however when run from the rust Command it ends up being the folder that the crate is being build it.

    Let me know if this makes better sense as an issue in the core Rust project. Right now I can't build emscripten since 1.20 fails and I can't get 1.19 to install the emscripten component when pinned to 1.19.

    opened by vvanders 24
  • [msvc] Don't use -M* flags.

    [msvc] Don't use -M* flags.

    Since this crate doesn't actually make decisions about final application linking, it's only appropriate to not interfere with the process. This can be achieved ~with -MT -Zl, because object modules compiled with these flags can be linked~ by relying on default MSVC behaviour that allows linking with either VCCRT version, static or dynamic, debug or release...

    It's suggested to use -Zl when building Rust static library. For reference, -Zl doesn't affect linking directives set with in Windows headers to add references to not-so-common libraries like mfc.lib, windowscodecs.lib to name just a pair.

    [Even an alternative solution to #717.]

    O-windows 
    opened by dot-asm 23
  • Cross-compilation of `zstd-sys` for `x86_64-pc-windows-msvc` target fails starting at 1.0.77

    Cross-compilation of `zstd-sys` for `x86_64-pc-windows-msvc` target fails starting at 1.0.77

    I am cross-compiling zstd-sys to x86_64-pc-windows-msvc in https://github.com/EFForg/apkeep/blob/5bffbf77cba71751884a46234dab66d83d5b0dbe/build-remote.sh#L75-L101. When cc is updated from 1.0.76 to 1.0.77, the build starts failing with the following:

      running: "clang-cl" "-nologo" "-MD" "-O2" "-Brepro" "-m64" "-Wno-unused-command-line-argument" "-fuse-ld=lld-link" "/imsvc/home/admin/xwin/crt/include" "/imsvc/home/admin/xwin/sdk/include/ucrt" "/imsvc/home/ad
    min/xwin/sdk/include/um" "/imsvc/home/admin/xwin/sdk/include/shared" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DXXH_PRIVATE_API=" "-DZSTDLIB
    _VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-Fo/home/admin/apkeep/target/x86_64-pc-windows-msvc/release/build/zstd-sys-6caf8d3f6c2dc823/out/zstd/lib/legacy/zstd
    _v06.o" "-c" "--" "zstd/lib/legacy/zstd_v06.c"
      cargo:warning=clang: warning: unknown argument ignored in clang-cl: '-fvisibility=hidden' [-Wunknown-argument]
      exit status: 0
      running: "clang-cl" "-nologo" "-MD" "-O2" "-Brepro" "-m64" "-Wno-unused-command-line-argument" "-fuse-ld=lld-link" "/imsvc/home/admin/xwin/crt/include" "/imsvc/home/admin/xwin/sdk/include/ucrt" "/imsvc/home/ad
    min/xwin/sdk/include/um" "/imsvc/home/admin/xwin/sdk/include/shared" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DXXH_PRIVATE_API=" "-DZSTDLIB
    _VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-Fo/home/admin/apkeep/target/x86_64-pc-windows-msvc/release/build/zstd-sys-6caf8d3f6c2dc823/out/zstd/lib/legacy/zstd
    _v02.o" "-c" "--" "zstd/lib/legacy/zstd_v02.c"
      cargo:warning=clang: warning: unknown argument ignored in clang-cl: '-fvisibility=hidden' [-Wunknown-argument]
      exit status: 0
      running: "clang-cl" "-nologo" "-MD" "-O2" "-Brepro" "-m64" "-Wno-unused-command-line-argument" "-fuse-ld=lld-link" "/imsvc/home/admin/xwin/crt/include" "/imsvc/home/admin/xwin/sdk/include/ucrt" "/imsvc/home/ad
    min/xwin/sdk/include/um" "/imsvc/home/admin/xwin/sdk/include/shared" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DXXH_PRIVATE_API=" "-DZSTDLIB
    _VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-Fo/home/admin/apkeep/target/x86_64-pc-windows-msvc/release/build/zstd-sys-6caf8d3f6c2dc823/out/zstd/lib/legacy/zstd
    _v03.o" "-c" "--" "zstd/lib/legacy/zstd_v03.c"
      cargo:warning=clang: warning: unknown argument ignored in clang-cl: '-fvisibility=hidden' [-Wunknown-argument]
      exit status: 0
      running: "clang-cl" "-nologo" "-MD" "-O2" "-Brepro" "-m64" "-Wno-unused-command-line-argument" "-fuse-ld=lld-link" "/imsvc/home/admin/xwin/crt/include" "/imsvc/home/admin/xwin/sdk/include/ucrt" "/imsvc/home/ad
    min/xwin/sdk/include/um" "/imsvc/home/admin/xwin/sdk/include/shared" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DXXH_PRIVATE_API=" "-DZSTDLIB
    _VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-Fo/home/admin/apkeep/target/x86_64-pc-windows-msvc/release/build/zstd-sys-6caf8d3f6c2dc823/out/zstd/lib/legacy/zstd
    _v05.o" "-c" "--" "zstd/lib/legacy/zstd_v05.c"
      cargo:warning=clang: warning: unknown argument ignored in clang-cl: '-fvisibility=hidden' [-Wunknown-argument]
      exit status: 0
      running: "clang-cl" "-nologo" "-MD" "-O2" "-Brepro" "-m64" "-Wno-unused-command-line-argument" "-fuse-ld=lld-link" "/imsvc/home/admin/xwin/crt/include" "/imsvc/home/admin/xwin/sdk/include/ucrt" "/imsvc/home/ad
    min/xwin/sdk/include/um" "/imsvc/home/admin/xwin/sdk/include/shared" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DXXH_PRIVATE_API=" "-DZSTDLIB
    _VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-Fo/home/admin/apkeep/target/x86_64-pc-windows-msvc/release/build/zstd-sys-6caf8d3f6c2dc823/out/zstd/lib/legacy/zstd
    _v04.o" "-c" "--" "zstd/lib/legacy/zstd_v04.c"
      cargo:warning=clang: warning: unknown argument ignored in clang-cl: '-fvisibility=hidden' [-Wunknown-argument]
      exit status: 0
      running: "ml64.exe" "-nologo" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-DZSTD_LIB_DEPRECATED=0" "-DXXH_PRIVATE_API=" "-DZSTDLIB_VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISI
    BILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-fvisibility=hidden" "-Fo/home/admin/apkeep/target/x86_64-pc-windows-msvc/release/build/zstd-sys-6caf8d3f6c2dc823/out/zstd/lib/decompress/huf_decompress_amd64.o" "-c" "zstd/li
    b/decompress/huf_decompress_amd64.S"
      exit status: 0
    
      --- stderr
    
    
      error occurred: Failed to find tool. Is `ml64.exe` installed?
    

    In 1.0.76 it succeeds.

    O-windows 
    opened by Hainish 21
  • Errors aren't shown to user

    Errors aren't shown to user

    In this gist the "explicit panic" is from a fail helper method that prints out the message. As you can see however, the actual message isn't show to the user. This kinda makes it hard to know what the error was.

    The message should probably be printed to stderr, not stdout, anyway.

    opened by Aatch 18
  • Support native library modifiers (RFC 2951)

    Support native library modifiers (RFC 2951)

    cc https://github.com/rust-lang/rust/issues/81490

    I haven't added a test because stabilization of the feature has just landed on nightly and is not available on stable yet, but I've tested it manually.

    Closes https://github.com/rust-lang/cc-rs/issues/689.

    opened by petrochenkov 15
  • Visual Studio 2017

    Visual Studio 2017

    https://github.com/alexcrichton/gcc-rs/blob/master/src/windows_registry.rs#L120 needs to be updated to look for whatever the version number for VS2017 is (16.0?)

    opened by emberian 15
  • Use a DWARF version consistent with rustc

    Use a DWARF version consistent with rustc

    Rustc defaults to DWARF-2 on some targets, and DWARF-4 on others. However using -g with the C compiler yields whatever default version the C compiler prefers.

    One side effect is that the DWARF debug info shipped in some libraries with rustc itself (e.g. libcompiler_builtins and others) have recently switched to DWARF-5 as a side effect of upgrading the clang version used on rustc CI. (https://github.com/rust-lang/rust/issues/98746)

    Ideally, the preferred DWARF version would be given by the rust compiler and/or cargo, but that's not the case at the moment, so the next best thing is something that aligns with the current defaults, although work in under way to add a rustc flag that would allow to pick the preferred DWARF version (https://github.com/rust-lang/rust/pull/98350)

    opened by glandium 14
  • New Maintainers

    New Maintainers

    I'm reaching the end of my tenure of maintaining this crate. I can't keep up with the constant inundation of platforms into this crate and this has outgrown my own personal ability to manage. I feel nowadays like all I can do is rubber stamp big changes since I have no idea how the targets work, but at the same time it seems to be the case that code is just dumped in this crate and no one ever looks at it again until there's a bug. Personally, I can't keep up with that any more.

    If someone would like to take over this crate please let me know. I realize though that this crate is very heavily depended on in the ecosystem, so I won't necessarily give this to the first person that shows up. I'll need to recognize you and you'll also need to understand the importance of this crate and its stability.

    opened by alexcrichton 12
  • Support finding Visual Studio instances using vswhere.exe

    Support finding Visual Studio instances using vswhere.exe

    This PR adds another option in attempting to find an installed Visual Studio version by using vswhere.exe.

    vswhere.exe has a known location (%ProgramFiles(x86)%\Microsoft Visual Studio\Installer) and is a 32-bit application which means it can be used on Windows ARM64 to locate Visual Studio (see https://github.com/rust-lang/rust/issues/83043).

    vswhere.exe is used as a last resort to find VS2015+ if everything else has failed. vswhere.exe itself is launched with parameters to search for only the latest available version that has component Microsoft.VisualStudio.Component.VC.Tools.<ARCH> installed.

    opened by Alovchin91 12
  • Add CUDA support for MSVC

    Add CUDA support for MSVC

    Tested building https://github.com/trolleyman/cuda-macros with this (the cuda-macros-test crate) and it builds & links correctly. Haven't had a chance to test that this runs yet, but will in the morning.

    I wasn't sure that this way is the most elegant, but this seemed like the way that did the least amount of changes. I am also not sure that this is the correct way of doing this, especially regarding cross-compiling, but it gets it up and running at least.

    To test you can do a cargo build in the root of the repo linked above. The build stuff is a bit hacky, but essentially it generates the CUDA function below & calls it.

    extern "C" __global__ void hello(int32_t* x, int32_t y) {
        printf("Hello from block %d, thread %d (y=%d)\n", blockIdx.x, threadIdx.x, y);
        *x = 2;
    }
    
    extern "C" unsafe fn hello(x: *mut i32, y: i32);
    
    opened by trolleyman 11
  • File::create in gcc-shim sometimes fails with multiple test threads

    File::create in gcc-shim sometimes fails with multiple test threads

    On macOS 10.14.5 (Mojave) with rustc 1.35.0 and 1.36.0, if I do the following with cc-rs at d2ba46f65cbf56b6b8852a3ab277c45259e38811:

    $ export RUST_BACKTRACE=full
    $ while cargo test; do sleep 0.00001; done
    

    I eventually get the following:

    cargo:warning=thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:997:5
    cargo:warning=stack backtrace:
    cargo:warning=   0:        0x10b4928c3 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::hf2949dcf16da83bd
    cargo:warning=   1:        0x10b48ed52 - std::sys_common::backtrace::_print::h4b87ed6ba0cd5304
    cargo:warning=   2:        0x10b491986 - std::panicking::default_hook::{{closure}}::hde39fed432870543
    cargo:warning=   3:        0x10b49172f - std::panicking::default_hook::hfce8820d41dbdcbf
    cargo:warning=   4:        0x10b49203f - std::panicking::rust_panic_with_hook::hfcf2d0777bc6c409
    cargo:warning=   5:        0x10b491b6c - std::panicking::continue_panic_fmt::h4d668741ea600293
    cargo:warning=   6:        0x10b491a58 - rust_begin_unwind
    cargo:warning=   7:        0x10b4a21a1 - core::panicking::panic_fmt::hdf67eedb88644e1e
    cargo:warning=   8:        0x10b487a1e - core::result::unwrap_failed::h72e112a4d5b9862c
    cargo:warning=   9:        0x10b487c2c - core::result::Result<T,E>::unwrap::hd3ca7ccf5659392e
    cargo:warning=  10:        0x10b48500a - gcc_shim::main::h533f983c23ce4b8d
    cargo:warning=  11:        0x10b485841 - std::rt::lang_start::{{closure}}::h02cd9a674d8a658f
    cargo:warning=  12:        0x10b491a37 - std::panicking::try::do_call::h1252fc9a2ff235eb
    cargo:warning=  13:        0x10b493a6e - __rust_maybe_catch_panic
    cargo:warning=  14:        0x10b4923fd - std::rt::lang_start_internal::h4c054360e442146c
    cargo:warning=  15:        0x10b485821 - std::rt::lang_start::h4f275a1c31c55923
    cargo:warning=  16:        0x10b485191 - main
    
    error occurred: Command "cc" "-O2" "-ffunction-sections" "-fdata-sections" "-m64" "-o" "/[...]/cc-rs/target/debug/gcc-test.m754lUmxjWLh/foo.o" "-c" "foo.c" with args "cc" did not execute successfully (status code exit code: 101).
    

    I cannot reproduce the panic if I replace cargo test with cargo test -- --test-threads 1.

    The panic comes arbitrarily from (a) one of the two uses of File::create in src/bin/gcc-shim.rs and (b) one of the stub executables (cc, ar, etc.)

    opened by spl 11
  • Prioritize RUSTC_LINKER over target->cross-compile-prefix table.

    Prioritize RUSTC_LINKER over target->cross-compile-prefix table.

    Rationale is that if rustc is explicitly instructed to use a specific linker, using it as base for cross-compile prefix would be better aligned with user expectations.

    This is in response to #766. Should fix #654.

    opened by dot-asm 0
  • Cross compile build failure

    Cross compile build failure

    When attempting to cross compile from aarch64-unknown-linux-gnu to x86_64-unknown-linux-musl this crate chooses a completely wrong compiler name: musl-gcc. The must-gcc compiler cannot be used to build x86_64 under an aarch64 machine.

    Why is cc-rs not using RUSTC_LINKER in this case which points to a valid compiler/linker for the target platform?

    opened by Yuri6037 1
  • Rebuild if changed

    Rebuild if changed

    When using the cc crate...

    what is the proper way to set up build.rs and/or Cargo.toml so that cargo will automatically recompile and relink the C/C++ files if they are changed since the last compilation? Maybe even list the local header files so changing them will trigger recompilation/relink as well?

    Alternatively, what is the proper way to force cargo to recompile all the C/C++ files?

    Right now I can always remove the target/{debug,release} directories to force recompilation but it seems like a hack.

    opened by orenbenkiki 7
  • Expose get_archiver and get_ranlib

    Expose get_archiver and get_ranlib

    This PR exposes cc's inferred archiver through a similar mechanism as get_compiler: with get_archiver/try_get_archiver.

    As part of this, I also realized that cc wouldn't pick up ARFLAGS, so I added support for that. Through that, I also realized that there was currently one place where we didn't respect Build::ar_flags when ar was called, so I fixed that too.

    Since ranlib is exposed more or less exactly like ar, I also added a get_ranlib/try_get_ranlib combination. This is, in part, to enable openssl-src to move to re-use cc's AR (and now RANLIB) detection rather than rolling its own. See alexcrichton/openssl-src-rs#164.

    Note that I didn't re-use Tool for the return value for these getter functions, and instead just exposed Command directly. Tool has a number of relatively compiler-specific things, so it felt wrong to use. One important caveat to this is that Command::get_program was only added in Rust 1.57.0, so users on older versions of Rust won't have a way to recover the inferred ar program path, but that feels like it's probably okay given that we didn't even expose get_archive until now.

    opened by jonhoo 2
  • build passes invalid `-nologo` and `-out:` flags to `ar` tool if specified in `AR` env var.

    build passes invalid `-nologo` and `-out:` flags to `ar` tool if specified in `AR` env var.

    Found this here: https://chromium-review.googlesource.com/c/chromium/src/+/4087043/4//COMMIT_MSG#26

    The AR env var can override the tool: https://github.com/rust-lang/cc-rs/blob/0e51f6d8a05548bd9991bfd8184b45b77b261a17/src/lib.rs#L2651-L2653

    However the flags passed to it include "-nologo" and -out: which then fails with invalid flag.

    https://github.com/rust-lang/cc-rs/blob/0e51f6d8a05548bd9991bfd8184b45b77b261a17/src/lib.rs#L2107-L2111

    It seems like if AR is specified in the env var, it shouldn't assume it can change the arguments based on the target being msvc?

    opened by danakj 16
  • Add method for specifying C/C++ standard version

    Add method for specifying C/C++ standard version

    As requested by https://github.com/rust-lang/cc-rs/issues/565.

    Please have a look at the documentation I have included. :)

    I am not doing any abstraction over special cases like the name for the work-in-progress standard version. It's just the basics.

    I want to propose adding this to cc because:

    • It should be useful fairly often, considering that using the right standard version can be critical to compiling modern code. I have a C++17 dependency in one of my projects, and I couldn't build my code interfacing with it without specifying the standard version, because even very new compilers seem to default to older versions. As far as I know, the compatibility between C++ versions isn't perfect, so that might be why.
    • It can save people the effort of having to consult both GCC/Clang and MSVC documentation, and improve the portability of code from people who haven't tested on Windows:
      • The GCC/Clang and MSVC flag syntaxes are not quite the same, so without support in the cc crate, the developer has to write conditional, platform-specific code.
      • The common subset of supported versions between GCC/Clang and MSVC is not something you can intuitively guess. The documentation added here can help.
    • While I haven't done that here, it could be enhanced in future to handle special cases like the different names for the WIP future C and C++ standards.
    opened by hikari-no-yume 0
Releases(1.0.78)
  • 1.0.78(Dec 15, 2022)

    Version 1.0.78

    Changelog

    • Now, only .asm files are passed to masm on windows targets, bringing things back in line with how cc-rs<1.0.77 handled it (#755).
    • Absolute paths in source are now mapped as relative in OUT_DIR (#684)
    • Several improvements were made to CUDA support (#712)
    • llvm-lib.exe is now used instead of lib.exe when clang-cl is used in an MSVC environment (#758)

    Thanks to everybody who contributed to this release!

    Source code(tar.gz)
    Source code(zip)
  • 1.0.77(Nov 20, 2022)

    Version 1.0.77

    Changelog

    • Added a new Build::asm_flag function, which allows providing flags that are only used when compiling assembly files (for example, if your C compiler rejects flags passed to the assembler when not used as an assembler). (#752)
    • Ensure that the version of DWARF debuginfo we emit is consistent with what rustc uses on the given target. (#694)

    Thanks to everybody who contributed to this release!

    Source code(tar.gz)
    Source code(zip)
  • 1.0.76(Nov 8, 2022)

    Version 1.0.76

    Changelog

    • When compiling with clang-cl, we now only use -- to separate flags/options from input files when not using the assembler, which doesn't support that option. This is a fix for a regression introduced in 1.0.74 (by #514) (present in 1.0.75 as well). (#747)

    This is essentially a bugfix release, so that's all!

    Source code(tar.gz)
    Source code(zip)
  • 1.0.75(Nov 8, 2022)

    Version 1.0.75

    Changelog

    • When Rust debuginfo is enabled, debuginfo is passed to MSVC assemblers (#742)
    • When locating an ar executable, *-ar is now preferred to *-gcc-ar (#741)
    • On MSVC 15+, the atlmfc directory is now correctly located (#699)

    Additionally, a number of smaller changes which shouldn't impact users have been made; see the commit history for complete details.

    Thanks to everybody who contributed to this release!

    Source code(tar.gz)
    Source code(zip)
  • 1.0.74(Oct 29, 2022)

    Version 1.0.74

    Changelog

    • When compiling with clang-cl, we now use -- to separate flags/options from input files. (#514)
    • We now fall back to RUSTC_LINKER's prefix (rather than erroring) if we fail to determine the prefix to use for the given target. (#685)
    • A Build::link_lib_modifier function was added to allow control which library modifiers are used when linking with the generated library. (#671)
    • When searching for an ar binary to use, we now try {target}-ar in addition to {target}-gcc-ar. If they're both present, {target}-ar will be preferred. (#735, #736)
    • We now emit cargo:rerun-if-env-changed messages for environment variables that influence the build. This is only done if cargo_metadata is enabled, and can be disabled by passing false to the new Build::emit_rerun_if_env_changed builder function. (#701, #738)

    New Targets

    The following targets are now supported:

    • The Apple WatchOS (and simulator) targets (*-watchos and *-watchos-sim). (#662)
    • The LLVM-based MinGW targets (*-pc-windows-gnullvm). (#734)
    • The Xous microkernel (riscv32imac-unknown-xous-elf). (#686)

    Additionally, a number of smaller changes which shouldn't impact users have been made; see the commit history for complete details.

    Thanks to everybody who contributed to this release!

    Source code(tar.gz)
    Source code(zip)
Owner
Alex Crichton
Alex Crichton
⚡ Fast Web Security Scanner written in Rust based on Lua Scripts 🌖 🦀

⚡ Fast Web Security Scanner written in Rust based on Lua Scripts ?? ??

Rusty Sec 14 Nov 28, 2022
Another cursed Garry's Mod module. This time, it adds the C preprocessor to Lua scripts

gm_cpreprocessor Another cursed Garry's Mod module. This time, it adds the C preprocessor to Lua scripts. It works by detouring RunStringEx and overri

William 6 Aug 14, 2022
Turns running Rust code into a serializable data structure.

WasmBox WasmBox turns running Rust code into a serializable data structure. It does this by compiling it to WebAssembly and running it in a sandbox. T

drifting in space 12 Dec 7, 2022
Build a python wheel from a dynamic library

build_wheel Small utility to create a Python wheel given a pre-built dynamic library (.so, .dylib, .dll). If you are just trying to produce a wheel fr

Tangram 1 Dec 2, 2021
Build frontend browser apps with Rust + WebAssembly. Supports server side rendering.

Percy Build frontend browser apps with Rust + WebAssembly. Supports server side rendering. The Percy Book This README gives a light introduction to Pe

Chinedu Francis Nwafili 2.1k Jan 1, 2023
Rust - Empowering everyone to build reliable and efficient software.

The Rust Programming Language This is the main source code repository for Rust. It contains the compiler, standard library, and documentation. Note: t

The Rust Programming Language 75.9k Dec 28, 2022
ruby-build is a command-line utility that makes it easy to install virtually any version of Ruby, from source.

ruby-build ruby-build is a command-line utility that makes it easy to install virtually any version of Ruby, from source. It is available as a plugin

null 3.7k Jan 5, 2023
An attempt to build full-featured WebAssembly-based monolith charts

Graphima Graphima (Greek: γράφημα) is an attempt to build full-featured WebAssembly-based monolith charts. See "Can I Use" WebAssembly for browser sup

Nikita Almakov 5 Jun 9, 2023
A weekly dive into commonly used modules in the Rust ecosystem, with story flavor!

Rust Module of the Week A weekly dive into commonly used modules in the Rust ecosystem, with story flavor! Build status Release Draft The goal The goa

Scott Lyons 20 Aug 26, 2022
Minimal framework to inject the .NET Runtime into a process in Rust

錆の核 sabinokaku Minimal framework to inject the .NET Runtime into a process. Supports Windows and Linux. macOS support is complicated due to SIP, and w

Snowflake Emulator Frontend 8 Mar 6, 2022
📦 Pack hundreds of Garry's Mod Lua files into just a handful

?? gluapack gluapack is a program that can pack hundreds of Garry's Mod Lua files into just a handful. Features Quick, easy and portable - perfect for

null 11 Aug 10, 2021
Inline CSS into style attributes

css-inline A crate for inlining CSS into HTML documents. It is built with Mozilla's Servo project components. When you send HTML emails, you need to u

Dmitry Dygalo 122 Dec 30, 2022
A small application to convert a 3D model in .obj format into HTML and CSS

obj-to-html is a small application that converts a 3D model in .obj format into HTML and CSS that will display that model in a web browser, spinning a

Andrea 7 Dec 30, 2022
A project for generating C bindings from Rust code

cbindgen   Read the full user docs here! cbindgen creates C/C++11 headers for Rust libraries which expose a public C API. While you could do this by h

Ryan Hunt 1.7k Jan 3, 2023
Run Java code from Rust!

Java Native Interface Bindings for Rust This library provides complete FFI bindings to the Java Native Interface, as well as a safe and intuitive wrap

Ben Anderson 66 Nov 28, 2022
Guarding 是一个用于 Java、JavaScript、Rust、Golang 等语言的架构守护工具。借助于易于理解的 DSL,来编写守护规则。Guarding is a guardians for code, architecture, layered.

Guarding Guarding is a guardians for code, architecture, layered. Using git hooks and DSL for design guard rules. Usage install cargo install guarding

Inherd OS Team (硬核开源小组) 47 Dec 5, 2022
A Web-App written in Rust with Yew, using the same SyntaxHighlighter from Google Code Archive as planetb.ca

PlanetB SyntaxHighlighter About This is a small app, providing static files to have a frontend to format your code so you can paste it with styles to

Christof Weickhardt 2 Dec 14, 2022
A collection of unsound rust functions using entirly *safe* code

A collection of unsound rust functions using entirly *safe* code

null 2 Sep 6, 2022
Rust solutions to problems in Advent of Code '22.

Advent of Code '22 This repository contains my solutions for AoC'22 problems, written in the language that will save us from cpp. Running the code The

Eshaan Aggarwal 2 Dec 15, 2022