rust-lang / cc-rs Goto Github PK

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

License: Apache License 2.0

Rust 99.57% C 0.19% C++ 0.03% Assembly 0.18% Cuda 0.03%

cc-rs's Introduction

cc-rs

A library for Cargo build scripts to compile a set of C/C++/assembly/CUDA files into a static archive for Cargo to link into the crate being built. This crate does not compile code itself; it calls out to the default compiler for the platform. This crate will automatically detect situations such as cross compilation and various environment variables and will build code appropriately.

Refer to the documentation for detailed usage instructions.

License

This project is licensed under either of

Apache License, Version 2.0, (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)

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.

cc-rs's People

Contributors

Stargazers

Watchers

Forkers

tomaka vhbit diamondlovesyou johnpmayer codyps bvssvni serholiu glennw servo abonander sondrele ltfschoen benjaminbollen kokakiwi sinistersnare vadimcn timnn sybblow aldaronlau jdub tempbottle ngrewe kosta peterhj apoelstra jarod phil-opp shepmaster fabricedesre gabrielesvelto rhenium timonvo sourcefrog frewsxcv retep998 jakllsch nipunn1313 brson uweigand alexbool japaric kamalmarhubi octo47 dflemstr paukstis parched jascha-n nagisa faultyram mbrubeck sfackler nitingupta910 binarycrusader zzeroo beamspease pietro cuviper zachreizner connorworley cactorium vvanders ppannuto liranringel jujis008 lucab ignatenkobrain king6cong opilar andygauge rap2hpoutre jehiggs ronnychevalier chrisvittal nivkner marcosatti vincenthage metajack boddlnagg jan-auer makotokato illicitonion grovesnl not-fl3 rrichardson glaubitz tbu- tjpalmer asonix edschouten kornelski mrmaxmeier simonsapin neivv jdm mixi gnzlbg mati865 mattico hsivonen geobert

cc-rs's Issues

Support a convention for specifying more paths to toolchain binaries

Currently cargo supports setting linker and ar in a config file, which is useful but is not always sufficient for cross-compiling crates that build native libraries.

While cross-compiling Servo I found that I had to specify quite a few extra tools to get everything to compile:
https://gist.github.com/luser/a33e5070d1c55a7d2c46fe763a9d1543#file-servo-cross-mac-L59

This was mostly because various crates used different build systems for building native libraries--autotools, cmake, etc. I think it'd be useful if the gcc crate supported a convention for specifying more tools in .cargo/config so that common crates for building native libraries (like cmake) could use that support to drive their builds.

Specifically, I think it would be useful if it allowed at least setting cc, cxx, ranlib, and exposed those values through its API.

README example is missing config arg

Cross compilation seems to be screwed up

I am using this to cross compile to my small arm board. It works awesomly: https://github.com/japaric/ruststrap/blob/master/1-how-to-cross-compile.md

I ran into problems with https://github.com/rust-lang/time/, a dependency of mio. It compiled fine, but at the linking stage I got errors:

$ cargo build --target arm-unknown-linux-gnueabihf --release
Compiling gcc v0.3.8
Compiling byteorder v0.3.10
Compiling libc v0.1.8
Compiling bytes v0.2.9
Compiling bitflags v0.1.1
Compiling log v0.3.1
Compiling nix v0.3.7
Compiling time v0.1.26
Compiling mio v0.3.6
Compiling hello v0.1.0 (file:///usr/local/google/home/hrapp/prog/rust_arm_crosscompile)
... verbose errors skipped
 /usr/local/google/home/hrapp/prog/rust_arm_crosscompile/target/arm-unknown-linux-gnueabihf/release/deps/libtime-85f806c28787f8bd.rlib: error adding symbols: File format not recognized

I traced that to time's c extension, build here: https://github.com/rust-lang/time/blob/master/build.rs
It seems to ignore the --target and happily build for another CPU. The fix is easy enough. In my own project I build with the CC variable set - but something seems fishy.

So this works:

$ CC=arm-linux-gnueabihf-gcc-4.8 cargo build --target arm-unknown-linux-gnueabihf --release
   Compiling gcc v0.3.8
   Compiling bytes v0.2.9
   Compiling byteorder v0.3.10
   Compiling bitflags v0.1.1
   Compiling libc v0.1.8
   Compiling log v0.3.1
   Compiling nix v0.3.7
   Compiling time v0.1.26
   Compiling mio v0.3.6
   Compiling hello v0.1.0 (file:///usr/local/google/home/hrapp/prog/rust_arm_crosscompile)
$

(optionally) emit warning messages from C(++) compiler

Once rust-lang/cargo#2630 lands, it would be awesome if there was an option to tell gcc-rs to forward the warning messages produced by the c/c++ compiler, but prefixed with cargo:warning=, to the build script's standard out. This would be useful for getting and fixing error messages in C++ and C code which is compiled through the build plugin as a companion to rust code.

Separating CFLAGS or CXXFLAGS by space causes problem in space separated paths

Environment: windows 7 x86_64, rust 1.8 msvc
When I am trying to build llvm-sys with msvc, this problem happens as LLVM is installed in the "Program Files" folder. This path is then separated into two different tokens and passed as two different parameters to the compiler, causing unintended effects
https://github.com/alexcrichton/gcc-rs/blob/master/src/lib.rs#L681

Use Rust's bundled gcc on Windows

Currently, gcc-rs requires gcc to be on the PATH. This works well enough on non-Windows platforms, where gcc can safely assumed to be present, but on Windows it requires installing MinGW. Rust and Cargo don't require MinGW, because Rust currently bundles the necessary parts of it (in C:\Program Files\Rust\bin\rustlib\x86_64-pc-windows-gnu\bin). gcc-rs should be able to use the bundled gcc.

Two things are needed for this to work; the first is that gcc-rs should use the gcc at the above path (or its 32-bit equivalent) if it isn't found in the PATH. The second is that the bundled gcc doesn't seem to work with this library:

C:\Users\Nathan\Dropbox\code\in-progress\tmp2>SET PATH=%PATH%;C:\Program Files\Rust\bin\rustlib\x86_64-pc-windows-gnu\bin

C:\Users\Nathan\Dropbox\code\in-progress\tmp2>gcc
gcc: fatal error: no input files
compilation terminated.

C:\Users\Nathan\Dropbox\code\in-progress\tmp2>C:\cargo\bin\cargo run
    Updating git repository `https://github.com/rust-lang/time`
    Updating git repository `https://github.com/alexcrichton/gcc-rs`
   Compiling gcc v0.0.2 (https://github.com/alexcrichton/gcc-rs#a3a9a261)
   Compiling time v0.0.3 (https://github.com/rust-lang/time#533d3823)
Failed to run custom build command for `time v0.0.3 (https://github.com/rust-lang/time#533d3823)`
Process didn't exit successfully: `C:\Users\Nathan\Dropbox\code\in-progress\tmp2\target\build\time-d924131696e54b12\build-script-build.exe` (status=101)
--- stdout
running: gcc '-O0' '-c' '-ffunction-sections' '-fdata-sections' '-m64' '-fPIC' 'C:\Users\Nathan\.cargo\git\checkouts\time-d59bff975f117a1a\master\src\time_helpers.c' '-o' 'C:\Users\Nathan\Dropbox\code\in-progress\tmp2\target\build\time-d924131696e54b12\out\src\time_helpers.o'

--- stderr
gcc: error: CreateProcess: No such file or directory
task '<main>' panicked at 'nonzero exit status: exit code: 1', C:\Users\Nathan\.cargo\git\checkouts\gcc-rs-49038096d5e74406\master\src\lib.rs:108

After adding the bundled gcc to the path, compilation still fails, but it works if I use MinGW64's gcc instead. I'm not sure what's going wrong here - perhaps gcc-rs has some dependencies other than gcc that aren't bundled with Rust?

Compilation failure when using opt-level=s/z

error: failed to run custom build command for `miniz-sys v0.1.7`
process didn't exit successfully: `/Users/alexbool/Documents/myproject/target/release/build/miniz-sys-60c8d67696f63a43/build-script-build` (exit code: 101)
--- stdout
TARGET = Some("x86_64-apple-darwin")
OPT_LEVEL = Some("s")

--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }', ../src/libcore/result.rs:799
stack backtrace:
   1:        0x10280491a - std::sys::backtrace::tracing::imp::write::h4b09e6e8c01db097
   2:        0x10280a4af - std::panicking::default_hook::{{closure}}::h1d3243f546573ff4
   3:        0x102809535 - std::panicking::default_hook::h96c288d728df3ebf
   4:        0x102809a86 - std::panicking::rust_panic_with_hook::hb1322e5f2588b4db
   5:        0x102809924 - std::panicking::begin_panic::hfbeda5aad583dc32
   6:        0x102809842 - std::panicking::begin_panic_fmt::h4fe9fb9d5109c4bf
   7:        0x1028097a7 - rust_begin_unwind
   8:        0x10282fadd - core::panicking::panic_fmt::h4395919ece15c671
   9:        0x1027f029b - core::result::unwrap_failed::h14ccca44a19c03b3
  10:        0x1027f6596 - gcc::Config::get_compiler::h5ef4cebb1abfacde
  11:        0x1027f1b3b - gcc::Config::compile::hcf84f0768b2f3c55
  12:        0x1027f132e - gcc::compile_library::hcb535ef1fb07196a
  13:        0x1027ef1df - build_script_build::main::h3a7bcbbe7711af63
  14:        0x10280aa6a - __rust_maybe_catch_panic
  15:        0x102809076 - std::rt::lang_start::haaae1186de9de8cb

error: visibility has no effect inside functions or block expressions

... \gcc-0.3.29\src\windows_registry.rs:341:5: 371:6 error: visibility has no effect inside functions or block expressions [E0447]
... \gcc-0.3.29\src\windows_registry.rs:341     pub fn host_arch() -> u16 {
... \gcc-0.3.29\src\windows_registry.rs:342         type DWORD = u32;
... \gcc-0.3.29\src\windows_registry.rs:343         type WORD = u16;
... \gcc-0.3.29\src\windows_registry.rs:344         type LPVOID = *mut u8;
... \gcc-0.3.29\src\windows_registry.rs:345         type DWORD_PTR = usize;
... \gcc-0.3.29\src\windows_registry.rs:346

Version gcc 0.3.28 worked just fine.

My rustc is 1.8.0 (db2939409 2016-04-11)

Support custom target files

Right now the crate uses only the target string for automatic configuration. For example, it compiles the dependencies with -fPIC if the target string does not contain i686 or windows-gnu. This can lead to surprising behavior when using custom target files since their values are completely ignored.

For example, the resulting library uses position independent code (and a global offset table) even if the target json contains "relocation-model": "static"… except for target files that have i686 somewhere in their file name. And renaming the file is the only option to override this automatic behavior.

Standard libraries fail to load with multiarch-ized Rust from Debian

I have installed rustc package from repositories on my Debian system, and cargo nightly from crates.io. In that package the libraries are located in the path /usr/lib/<target-triplet>/rust/<version>/lib, instead of /usr/local/lib, where the official binary distributions tend to install them.

Running Cargo build scripts which use this crate to compile and link in arbitrary C code ends for me with an error like this:

/home/user/Projects/gcctest/target/debug/build/gcctest-418d8ec1530ca096/build-script-build: error while loading shared libraries: libstd-4e7c5e5c.so: cannot open shared object file: No such file or directory

With Rust binaries from the official site, however, everything works just fine.

Build Error

When building I get the following error.

Compiling gcc v0.3.2 (file:///Users/matthewmccoy/rust/gcc-rs)
src/lib.rs:225:35: 225:58 error: type `std::io::error::ErrorKind` does not implement any method in scope named `NotFound`
src/lib.rs:225         Err(ref e) if e.kind() == io::ErrorKind::NotFound => {
                                                 ^~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
Could not compile `gcc`.

To learn more, run the command again with --verbose.

Output from rustc --version

rustc 1.0.0-nightly (30e1f9a1c 2015-03-14) (built 2015-03-15)

C++ Standard Library on OS X

(I'm no expert in these things, all information here is based on (recent) experience and some google-fu).

On OS X there are two difference C++ standard libraries: libc++ and libstdc++. The clang shipped with OS X (which is also the default compiler) uses libc++ by default, whereas gcc uses libstdc++. When compiling c++ code, gcc-rs automatically links to libstdc++.

This leads to errors at link time. One can work around this problem by either setting CXX to a real gcc (not the one shipped with OSX, which also uses libc++) or setting CXXFLAGS to -stdlib=libstdc++.

A third alternative would be if it were possible to instruct gcc-rs to link to libc++ instead of libstdc++.

I'm not sure what exactly the best solution for gcc-rs would be, but I think following goes in the right direction:

if gcc-rs automatically links to libsdc++, it should ensure that the compiler uses that specific standard library by automatically specifying -stdlib=libstdc++.
Config::cpp should probably take a second argument, which forces the user to think about which standard library to use. Possible values could be LibStdCpp, LibCpp, PlatformDefault (LibCpp on OS X, LibStdCpp on anything else) and NoStdLib (don't specify -stdlib but neither automatically link to a standard library).

If this sounds good, I would be happy to implement these changes.

Is hardcoding -mwin32 on windows targets a good idea?

See sfackler/rust-openssl#248

Adding the -mwin32 flag as default in gcc-rs is the reason that openssl-sys is failing to compile under Cygwin. The openssl code seems to be expecting that, under Cygwin, the _WIN32 is not defined.

What do you feel is the best way to handle this problem?

It makes sense to me that since the -mwin32 flag is not a gcc default, that projects that need -mwin32 should add it to their gcc flags.

It doesn't make sense to me that projects that don't want -mwin32 should be required to opt out of it because gcc-rs has it as a default.

What do you think?

support $CC, $CXX containing spaces

(from rust-lang/rust#32914)

A setting of CC='ccache gcc' is accepted by most Linux build tools but causes trouble for Rust. When it builds an argv to execute the compiler it treats that whole string as the binary name.

This is apparently intentional but might not be optimal.

Probably better is to either

split on spaces
or perhaps use some shell-like parser to break into words, which might allow for quoted spaces etc

cargo:rustc-link-lib=static=brotli-dec
cargo:rustc-link-search=native=/home/mbp/src/conserve/target/debug/build/brotli-sys-c29cf30a86d86a13/out
TARGET = Some("x86_64-unknown-linux-gnu")
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-unknown-linux-gnu")
debug=true opt-level=0
HOST = Some("x86_64-unknown-linux-gnu")
TARGET = Some("x86_64-unknown-linux-gnu")
TARGET = Some("x86_64-unknown-linux-gnu")
HOST = Some("x86_64-unknown-linux-gnu")
CXX_x86_64-unknown-linux-gnu = None
CXX_x86_64_unknown_linux_gnu = None
HOST_CXX = None
CXX = Some("ccache c++")
TARGET = Some("x86_64-unknown-linux-gnu")
HOST = Some("x86_64-unknown-linux-gnu")
CXXFLAGS_x86_64-unknown-linux-gnu = None
CXXFLAGS_x86_64_unknown_linux_gnu = None
HOST_CXXFLAGS = None
CXXFLAGS = None
running: "ccache c++" "-O0" "-ffunction-sections" "-fdata-sections" "-g" "-m64" "-fPIC" "-I" "brotli/enc" "-I" "src" "-o" "/home/
mbp/src/conserve/target/debug/build/brotli-sys-c29cf30a86d86a13/out/src/brotli_capi.o" "-c" "src/brotli_capi.cc"

failed to execute command: No such file or directory (os error 2)
Is `ccache c++` not installed?

Can't compile C sources with `-lxcb` flag

I need to run the compiler with the flag -lxcb to compile my C sources, however all methods in this library for adding flags add them at the wrong location. I need the -lxcb flag after the sources.

I tried adding .flag("-lxcb") to the build file, however that added the flag before the sources, I also tried the CFLAGS environment variable, however that did the same.

What I get:

running: "cc" "-O0" "-c" "-ffunction-sections" "-fdata-sections" "-m64" "-fPIC" "-I" "src" "-lxcb" "/home/user/src/nvim-wm/src/xcb/xcb.c" "-o" "/home/user/src/nvim-wm/target/debug/build/nvim-wm-c5c5e07d2e28bf98/out/src/xcb/xcb.o"

What I want:

running: "cc" "-O0" "-c" "-ffunction-sections" "-fdata-sections" "-m64" "-fPIC" "-I" "src" "/home/user/src/nvim-wm/src/xcb/xcb.c" "-o" "/home/user/src/nvim-wm/target/debug/build/nvim-wm-c5c5e07d2e28bf98/out/src/xcb/xcb.o" "-lxcb"

Default musl compiler binary names are dodgy

An installation of musl does not supply a musl-g++, but this crate assumes that it exists for C++ code. This is a bit a of a quandry to solve. It also assumes things like musl-gcc exist, which isn't really true unless musl has been installed alongside glibc on an existing system as a system compiler - not a cross compiler. Since most build.rs scripts are often targeting a cross-compilation, rather than deployment on the host (especially so if --target has been passed to cargo), using a reference to the system compiler seems wrong.

A slightly better approach might be to support the names used by musl-cross-make, eg x86_64-linux-musl-cc. This allows installation of multiple copies of musl targeting gcc (or clang) at different architectures to co-exist. These names are also the ones available by default if installing musl-cross-make on Mac OS X using Homebrew (https://github.com/FiloSottile/homebrew-musl-cross/)

Sadly, it's very difficult trying to overcome the mess of C compilation, and particularly C cross compilation using gcc, which doesn't understand how to compile for more than target. We're also trying to accommodate scenarios ranging from install and run locally to deployment. Personally, I'd make cross compilation my primary focus, and make local install and run secondary; that way, when cross compilation's sorted, local install should just work. This is the approach taken by most from-scratch toolchains and the like (eg Linux from Scratch).

MinGW can't compile anything with -m64 flag on x86_64

On Windows with MinGW toolchain "-m64" flag causes "sorry, unimplemented: 64-bit mode not compiled in" error e.g. when compiling miniz-sys:

C:\...\.cargo\registry\src\github.com-0a35038f75765ae4\miniz-sys-0.1.6\miniz.c:1:0: sorry, unimplemented: 64-bit mode not compiled in
thread '<main>' panicked at 'explicit panic', C:\...\.cargo\registry\src\github.com-0a35038f75765ae4\gcc-0.3.13\src\lib.rs:510

miniz.c compiles fine without -m64 flag.

Add ATL/MFC include directories to MSVC compiler invocation if available

The ATL/MFC include directory (<VC directory>\atlmfc\include) is currently not passed to cl.exe. The library directory (<VC directory>\atlmfc\lib, <VC directory>\atlmfc\lib\arm or <VC directory>\atlmfc\lib\amd64) are also not passed to the linker invocation. Mind you, the ATL and MFC libraries are not included with every installation of Visual Studio.

If the idea is for the user to add these directories manually, it would be very useful if we could reuse the MSVC installation detection code in this crate. Maybe by adding a find_vc_dir(target: &str) function to windows_registry?

Fix MSVC compiler detection when using the Visual C++ 2015 build tools standalone package.

gcc-rs does not properly detect the msvc compiler when installed with the Visual C++ 2015 build tools package from http://landinghub.visualstudio.com/visual-cpp-build-tools

The resulting registry keys are here: VSKeys.txt

rustc correctly determines the install location to find link.exe

Add links and a description to Cargo.toml

Right now it's basically impossible to tell what this package is, or where it comes from, by looking at the crates.io page

Output from gcc should be shown when the build fails

Currently a failing build (i.e. gcc returning an exit status != 0) just prints command did not execute successfully, got: exit code: ..., without providing any more detail about what the problem is. Printing stdout/stderr too would probably be helpful.

e.g. http://stackoverflow.com/q/29932255/1256624 was hard to diagnose without running the command manually.

tests don't work on windows if run from D:\

The tests need to be run on the same drive as the temp folder.

thread 'gnu_define' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 17, message: "Das System kann die Datei nicht auf ein anderes Laufwerk verschieben.\r\n" } }', ../src/libcore\result.rs:732

The issue is that some files are moved instead of copied according to the error message and the docs: https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382%28v=vs.85%29.aspx

type `&std::path::Path` does not implement any method in scope named `to_owned`

The library does not compile for me with the following error messages

   Compiling gcc v0.3.18
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:268:46: 268:56 error: type `&std::path::Path` does not implement any method in scope named `to_owned`
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:268         self.out_dir = Some(out_dir.as_ref().to_owned());
                                                                                                                                      ^~~~~~~~~~
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:268:56: 268:56 help: methods from traits can only be called if the trait is in scope; the following trait is implemented but not in scope, perhaps add a `use` for it:
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:268:56: 268:56 help: candidate #1: use `collections::borrow::ToOwned`
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:278:48: 278:58 error: type `&std::path::Path` does not implement any method in scope named `to_owned`
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:278         self.compiler = Some(compiler.as_ref().to_owned());
                                                                                                                                        ^~~~~~~~~~
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:278:58: 278:58 help: methods from traits can only be called if the trait is in scope; the following trait is implemented but not in scope, perhaps add a `use` for it:
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:278:58: 278:58 help: candidate #1: use `collections::borrow::ToOwned`
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:288:48: 288:58 error: type `&std::path::Path` does not implement any method in scope named `to_owned`
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:288         self.archiver = Some(archiver.as_ref().to_owned());
                                                                                                                                        ^~~~~~~~~~
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:288:58: 288:58 help: methods from traits can only be called if the trait is in scope; the following trait is implemented but not in scope, perhaps add a `use` for it:
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:288:58: 288:58 help: candidate #1: use `collections::borrow::ToOwned`
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:303:35: 303:45 error: type `&std::ffi::os_str::OsStr` does not implement any method in scope named `to_owned`
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:303         self.env.push((a.as_ref().to_owned(), b.as_ref().to_owned()));
                                                                                                                           ^~~~~~~~~~
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:303:45: 303:45 help: methods from traits can only be called if the trait is in scope; the following trait is implemented but not in scope, perhaps add a `use` for it:
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:303:45: 303:45 help: candidate #1: use `collections::borrow::ToOwned`
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:303:58: 303:68 error: type `&std::ffi::os_str::OsStr` does not implement any method in scope named `to_owned`
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:303         self.env.push((a.as_ref().to_owned(), b.as_ref().to_owned()));
                                                                                                                                                  ^~~~~~~~~~
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:303:68: 303:68 help: methods from traits can only be called if the trait is in scope; the following trait is implemented but not in scope, perhaps add a `use` for it:
/home/dritscht/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.18/src/lib.rs:303:68: 303:68 help: candidate #1: use `collections::borrow::ToOwned`
error: aborting due to 5 previous errors
Could not compile `gcc`.

I'm using rust version 1.0.0-beta (9854143cb 2015-04-02) (built 2015-04-02) and the current master branch of gcc-rs (0.3.18)
OS is OpenSUSE 13.1 (Kernel 3.11.10-29-desktop)

Any ideas?
Thanks!

P.S.: I'm using 0.3.13 (3a44fdd) for now, which does not include the to_owned() changes yet

Support for parallel compilation

Would be nice to compile files in parallel (equivalent to make -j4 for example).

error: the trait `core::fmt::String` is not implemented for the type


$ cargo test
error: the trait `core::fmt::String` is not implemented for the type `core::option::Option<collections::string::String>` [E0277]
/Users/alex/.cargo/git/checkouts/gcc-rs-49038096d5e74406/master/src/lib.rs:28     println!("{} = {}", v, r);
                                                                                                         ^
note: in expansion of format_args!
<std macros>:2:42: 2:75 note: expansion site
<std macros>:1:1: 2:77 note: in expansion of println!
/Users/alex/.cargo/git/checkouts/gcc-rs-49038096d5e74406/master/src/lib.rs:28:5: 28:31 note: expansion site
/Users/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.1.0/src/lib.rs:102:29: 102:32 error: the trait `core::fmt::Display` is not implemented for the type `&mut std::io::process::Command` [E0277]
/Users/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.1.0/src/lib.rs:102     println!("running: {}", cmd);
                                                                                                                 ^~~
note: in expansion of format_args!
<std macros>:2:42: 2:75 note: expansion site
<std macros>:1:1: 2:77 note: in expansion of println!
/Users/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.1.0/src/lib.rs:102:5: 102:34 note: expansion site
/Users/alex/.cargo/git/checkouts/gcc-rs-49038096d5e74406/master/src/lib.rs:106:29: 106:32 error: the trait `core::fmt::Display` is not implemented for the type `&mut std::io::process::Command` [E0277]
/Users/alex/.cargo/git/checkouts/gcc-rs-49038096d5e74406/master/src/lib.rs:106     println!("running: {}", cmd);
                                                                                                           ^~~
note: in expansion of format_args!
<std macros>:2:42: 2:75 note: expansion site
<std macros>:1:1: 2:77 note: in expansion of println!
/Users/alex/.cargo/git/checkouts/gcc-rs-49038096d5e74406/master/src/lib.rs:106:5: 106:34 note: expansion site
error: aborting due to previous error
Build failed, waiting for other jobs to finish...
error: aborting due to 2 previous errors
Could not compile `gcc`.

$ cargo -V
cargo 0.0.1-pre-nightly (bb28e71 2015-01-22 06:06:34 +0000)

$ rustc -V
rustc 1.0.0-nightly (4be79d6ac 2015-01-23 16:08:14 +0000)

Support for opt-level {s,z}

Cargo now supports opt-level="s". However, cross-compiling using this crate fails with, e.g.:

error: failed to run custom build command for `liblmdb-sys v0.2.1`
process didn't exit successfully: `/home/joerg/Development/git/librespot/target/release/build/liblmdb-sys-4670f3f0ac13a883/build-script-build` (exit code: 101)
--- stdout
TARGET = Some("armv5te-unknown-linux-musl")
OPT_LEVEL = Some("s")

Build on only stable rust

Needed unstable APIs:

std::convert::AsRef

cc iron/iron#317

I'm filing this issue because this crate is part of iron or hyper's dependency chain, and I'm working with @aturon to get both building with only stable APIs for 1.0, so we are tracking used unstable APIs.

When using VC15, stdlib.h isn’t found

I’m using Visual Studio 15 (beta), and if I don’t run vcvars64.bat my code which depends on flate2 which depends on miniz-sys which depends on miniz.c fails to compile:

   Compiling miniz-sys v0.1.7
Build failed, waiting for other jobs to finish...
error: failed to run custom build command for `miniz-sys v0.1.7`
process didn't exit successfully: `C:\path\to\my-crate\target\debug\build\miniz-sys-60c8d67696f63a43\build-script-build` (exit code: 101)
--- stdout
TARGET = Some("x86_64-pc-windows-msvc")
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-pc-windows-msvc")
debug=true opt-level=0
HOST = Some("x86_64-pc-windows-msvc")
TARGET = Some("x86_64-pc-windows-msvc")
TARGET = Some("x86_64-pc-windows-msvc")
HOST = Some("x86_64-pc-windows-msvc")
CC_x86_64-pc-windows-msvc = None
CC_x86_64_pc_windows_msvc = None
HOST_CC = None
CC = None
TARGET = Some("x86_64-pc-windows-msvc")
HOST = Some("x86_64-pc-windows-msvc")
CFLAGS_x86_64-pc-windows-msvc = None
CFLAGS_x86_64_pc_windows_msvc = None
HOST_CFLAGS = None
CFLAGS = None
running: "C:\\Program Files (x86)\\Microsoft Visual Studio 15.0\\VC/bin\\amd64\\cl.exe" "/nologo" "/MD" "/Z7" "/FoC:\\path\\to\\my-crate\\target\\debug\\build\\miniz-sys-60c8d67696f63a43\\out\\miniz.o" "/c" "miniz.c"
miniz.c
miniz.c(177): fatal error C1083: Cannot open include file: 'stdlib.h': No such file or directory
ExitStatus(ExitStatus(2))


command did not execute successfully, got: exit code: 2



--- stderr
thread 'main' panicked at 'explicit panic', C:\Users\me\.cargo\registry\src\github.com-1ecc6299db9ec823\gcc-0.3.28\src\lib.rs:840
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Latest rustc nightly.

Latest nightly compiler panics when compiling gcc-rs

If you download the latest compiler, and attempt to compile gcc-rs (cargo build), you'll get an error like the following:

% cargo build
   Compiling gcc v0.1.2 (file://path/to/gcc-rs)
/path/to/gcc-rs/src/lib.rs:77:9: 77:18 error: internal compiler error: create_for_loop_var_metadata() - Referenced variable location is not an alloca!
/path/to/gcc-rs/src/lib.rs:77     for directory in config.include_directories.iter() {
                                      ^~~~~~~~~
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/libsyntax/diagnostic.rs:123


Could not compile `gcc`.

To learn more, run the command again with --verbose.

As the compiler output states, this is a bug with rustc, but it also could be manifest due to a bug in gcc-rs. So I thought I'd report it here.

(rust version: rustc 0.13.0-nightly (34d680009 2014-12-22 00:12:47 +0000))
(cargo version: cargo 0.0.1-pre-nightly (e11c317 2014-12-21 20:43:45 +0000))

Rename the crate

Should this crate be renamed to something more generic like c_compiler? I've seen the current name cause confusion for people since they don't expect it to be able to work with MSVC, for example.

If a name change is desired this is potentially blocked on crates.io having support for renaming crates smoothly so dependent crate authors can be notified of the new name.

Command Line Option Not Supported In All Versions Of Gcc

I get this error:
c++: error: unrecognized command line option ‘-stdlib=libstdc++’
When I try to compile c++ code from my rust build script with .cpp(true)
It appears as though -stdlib=libstdc++ is not an accepted parameter by my version of gcc.

gcc-rs picks up .o files from previous builds unless cargo clean is run

I'm unsure whether this will be considered a cargo or gcc-rs bug but I ran into an interesting bit of behavior using cargo and gcc-rs together. Using gcc-rs in build.rs, I specified a .c file to build. I then changed the name of the .c file and built again. Linking started to fail with the following error message:

/home/jbaublitz/Source/Repos/Projects/surge/target/debug/build/surge-29091b15abafbbfc/out/libnetlink.a(netlink.o):(.rodata.nl_route+0x0): first defined here
/home/jbaublitz/Source/Repos/Projects/surge/target/debug/build/surge-29091b15abafbbfc/out/libnetlink.a(netlink_macros.o):(.rodata.nl_unused+0x0): multiple definition of `nl_unused'

and this message came up for all of the variables defined globally in my .c file. It seems that either cargo or gcc-rs is picking up both of the .o files and creating a .a file out of the stale and current .o files so therefore it believes the variables are defined twice.

This is the link to the build.rs file in question.

https://github.com/jbaublitz/surge/blob/master/build.rs

Does this seem like a gcc-rs issue or should I file it with cargo?

Add try_compile, returning Result<(), String>

The String could be stderr from the command.

This could be used to try to provide help messages, by checking the stderr, noticing an error about something like a missing header file, and suggesting to the user instructions on how to install those headers.

Support for overriding CC, CXX, CFLAGS, CXXFLAGS from a config file

I'm a windows user, and i've got mingw64 installed. Either add mingw64 dirs into PATH or setting CC CXX etc i can get things compiled. However i prefer not to do so, because i've got msys2 toolchains and msvc toolchains too. I'd rather keep things separated instead of messing them together.

I wonder if gcc-rs can load these from a separate overriding config file (only used by itself), so i don't have to tweak the whole system environment.

Invoking clang

My target does not have a gcc for it, only clang. (Nor a symlink from the gcc command.)

I would like to have a way to explicitly override the compiler binary used, or at least a name.

Parallel compilation crashes on directory creation

Sometimes I'm seeing this crash. Unfortunately, I am on mac, so I don't have fantastic stack traces. (Tried to replay sujayakar's work, but got a bit stuck figuring out binary load-addresses and offsets. Would be nice if the stack trace dumped the load-address as well).

In any case, I tracked this crash down to the fs::create_dir_all function being non-threadsafe. It checks if a directory exists and creates it if not. I'm working on a fix.

called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 17, message: "File exists" } }', ../src/libcore/result.rs:788
   1:        0x10c32fe19 - std::sys::backtrace::tracing::imp::write::h482d45d91246faa2
   2:        0x10c336250 - std::panicking::default_hook::_{{closure}}::h89158f66286b674e
   3:        0x10c3354e0 - std::panicking::default_hook::h9e30d428ee3b0c43
   4:        0x10c335b66 - std::panicking::rust_panic_with_hook::h2224f33fb7bf2f4c
   5:        0x10c335a04 - std::panicking::begin_panic::hcb11a4dc6d779ae5
   6:        0x10c335912 - std::panicking::begin_panic_fmt::h310416c62f3935b3
   7:        0x10c335877 - rust_begin_unwind
   8:        0x10c35c5b0 - core::panicking::panic_fmt::hc5789f4e80194729
   9:        0x10c2df67c - core::result::unwrap_failed::h738bbe05829f9dad
  10:        0x10c2d70ee - _<core..result..Result<T, E>>::unwrap::h532aaa3a5ea74623
  11:        0x10c2f1cbb - gcc::Config::compile_object::h2a3ed52bfecb7e4d
  12:        0x10c2f87ff - gcc::Config::compile_objects::_{{closure}}::h0a2401a1cceb25ff
  13:        0x10c2c8567 - _<rayon..par_iter..for_each..ForEachConsumer<'f, OP> as rayon..par_iter..internal..Folder<ITEM>>::consume::h0a7f5ff65a13dfb8
  14:        0x10c2e728a - rayon::par_iter::internal::bridge_producer_consumer::h351529e475a1c807
  15:        0x10c2faea8 - rayon::par_iter::internal::bridge_producer_consumer::_{{closure}}::h44cf79169bdc1e60
  16:        0x10c2e3c89 - _<rayon..job..JobImpl<L, F, R>>::run_result::h1b7b970c1985928c
  17:        0x10c2eccc5 - _<rayon..job..JobImpl<L, F, R> as rayon..job..Job>::execute::h406faa2e797b76d2
  18:        0x10c30edfa - rayon::thread_pool::main_loop::h8c27b4fcac8c252e
  19:        0x10c30fa36 - rayon::thread_pool::Registry::new::_{{closure}}::hc30eb676db7bf4a6
  20:        0x10c30be5f - _<std..panic..AssertUnwindSafe<F> as core..ops..FnOnce<()>>::call_once::h709feae4d04ad6d4
  21:        0x10c30087d - std::panicking::try::do_call::h699720cb2ad0bb7c
  22:        0x10c33683a - __rust_maybe_catch_panic
  23:        0x10c3005d2 - std::panicking::try::hbf87ab9d80d451a0
  24:        0x10c2ff7fe - std::panic::catch_unwind::h62851ebd6e8d6212
  25:        0x10c30f5eb - std::thread::Builder::spawn::_{{closure}}::h5c0f316c49bcea9a
  26:        0x10c30780b - _<F as alloc..boxed..FnBox<A>>::call_box::hfeecd61354d23530
  27:        0x10c334cd5 - std::sys::thread::Thread::new::thread_start::he0bf102845911132
  28:     0x7fff8eb3599c - _pthread_body
  29:     0x7fff8eb35919 - _pthread_start

link error

My project runs on Windows, there is an error undefined reference to EnumProcesses in c code.

I know the function EnumProcesses() defined in libpsapi.a, and i find this library in C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib.

I tried to use object() and flag() in gcc-rs to link the library, but failed.

How can i fix it?

Steer Windows users towards correct information about installing gcc

Given the confusing naming of various mingw forks floating around Internet, it is unlikely that inexperienced Windows users will manage to install the right one (example).
I think we should supplement is 'gcc' not installed? message with a link to the corrent information. Not sure where exactly... we used to have "Windows" page in Rust wiki, but that is now gone.

Call emcc when building for emscripten

Supporting this could help port a number of different libraries that need to build individual C files to emscripten. A notable example is "flate2-rs", which needs to build "miniz.c", which can be compiled without errors by emcc.

PATH environment variable also required for Mac when gcc installed

I tried using gcc-rs as follows:

Cargo.toml was updated with the following:

[package]
links = "hello"
build = "build.rs"

[build-dependencies.gcc]
git = "https://github.com/alexcrichton/gcc-rs"

build.rs file was created in the same directory as Cargo.toml with the following contents:

extern crate gcc;

fn main() {
    gcc::Config::new()
                .file("src/c/hello.c")
                .include("src")
                .compile("libhello.a");
}

hello.c source code was created in ./src/c/

#include <stdio.h>

void hello() {
    printf("Hello, World!\n");
}

main.rs Crate Root was created in ./src

use std::old_io;

fn main() {
    #[link(name="hello", kind="static")]
    extern { fn hello(); }
    unsafe { hello(); };
}

With this configuration, when I run cargo run it successfully compiles and prints "Hello, World!" in the terminal.

However, when I changed Cargo.toml to the following (instead of grabbing the gcc-rs dependency from the GitHub repo) I got the following errors, which indicates to me that something needs to be added to .bash_profile (the PATH) on Mac's too (I am using OSX 10.9.5). Currently the gcc-rs README file indicates that PATH updates only need to be made on Windows:
[build-dependencies]
gcc = "0.2"

build.rs:10:26: 10:31 error: mismatched types:
 expected `std::old_path::posix::Path`,
    found `&'static str`
(expected struct `std::old_path::posix::Path`,
    found &-ptr) [E0308]
build.rs:10                 .include("src")

I assume that .bashrc would need to be updated somehow?

if [ -d /Users/<username>/code/my_project ];
then
   GCC_LIBRARY_PATH=/Users/<username>/code/my_project:$LD_LIBRARY_PATH
fi

export GCC_LIBRARY_PATH

Illegal invocation of cl.exe when targeting i686-pc-windows-msvc from x86_64-apple-darwin

gcc-rs illegally invokes cl.exe's /Fo<pathname> parameter by inserting a colon before the pathname, when cross-compiling from x86_64-apple-darwin to i686-pc-windows-msvc.

Invoking with INCLUDE="$HOME/i686-pc-windows-msvc-w10/include;$HOME/i686-pc-windows-msvc-vc10/include" LIB="$HOME/i686-pc-windows-msvc-w10/lib;$HOME/i686-pc-windows-msvc-vc10/lib" TARGET_CC=cl.exe cargo build --target i686-pc-windows-msvc, where cl.exe is a symlink to clang-cl, yields an error like:

   Compiling rust-crypto v0.2.34 (file:///Users/alex/GitHub/rust-crypto)
failed to run custom build command for `rust-crypto v0.2.34 (file:///Users/alex/GitHub/rust-crypto)`
Process didn't exit successfully: `/Users/alex/GitHub/rust-crypto/target/debug/build/rust-crypto-6ae07b54d3ad34fc/build-script-build` (exit code: 101)
--- stdout
TARGET = Some("i686-pc-windows-msvc")
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("i686-pc-windows-msvc")
debug=true opt-level=0
HOST = Some("x86_64-apple-darwin")
TARGET = Some("i686-pc-windows-msvc")
TARGET = Some("i686-pc-windows-msvc")
HOST = Some("x86_64-apple-darwin")
CC_i686-pc-windows-msvc = None
CC_i686_pc_windows_msvc = None
TARGET_CC = Some("cl.exe")
TARGET = Some("i686-pc-windows-msvc")
HOST = Some("x86_64-apple-darwin")
CFLAGS_i686-pc-windows-msvc = None
CFLAGS_i686_pc_windows_msvc = None
TARGET_CFLAGS = None
CFLAGS = None
running: "cl.exe" "/nologo" "/MD" "/Z7" "/Fo:/Users/alex/GitHub/rust-crypto/target/i686-pc-windows-msvc/debug/build/rust-crypto-6ae07b54d3ad34fc/out/src/util_helpers.o" "/c" "src/util_helpers.c"
ExitStatus(ExitStatus(256))


command did not execute successfully, got: exit code: 1



--- stderr
error: unable to open output file ':/Users/alex/GitHub/rust-crypto/target/i686-pc-windows-msvc/debug/build/rust-crypto-6ae07b54d3ad34fc/out/src/util_helpers.o': 'No such file or directory'
1 error generated.
thread '<main>' panicked at 'explicit panic', /Users/alex/.cargo/registry/src/github.com-88ac128001ac3a9a/gcc-0.3.20/src/lib.rs:772

Notice the illegal argument /Fo:/Users/alex/GitHub/rust-crypto/target/i686-pc-windows-msvc/debug/build/rust-crypto-6ae07b54d3ad34fc/out/src/util_helpers.o. This should be /Fo/Users/alex/GitHub/rust-crypto/target/i686-pc-windows-msvc/debug/build/rust-crypto-6ae07b54d3ad34fc/out/src/util_helpers.o.

Indeed manually compiling with INCLUDE="$HOME/i686-pc-windows-msvc-w10/include;$HOME/i686-pc-windows-msvc-vc10/include" LIB="$HOME/i686-pc-windows-msvc-w10/lib;$HOME/i686-pc-windows-msvc-vc10/lib" "cl.exe" "/nologo" "/MD" "/Z7" "/Fo/Users/alex/GitHub/rust-crypto/target/i686-pc-windows-msvc/debug/build/rust-crypto-6ae07b54d3ad34fc/out/src/util_helpers.o" "/c" "src/util_helpers.c" works fine.

Support MIPS little-endian targets

Currently when cross-compiling for MIPS the only supported prefix is the one for big-endian targets (mips-unknown-linux-gnu), little-endian targets have their own prefix that should be added to the supported prefix list (mipsel-unknown-linux-gnu).

Also, using an unsupported prefix silently uses the host compiler which doesn't seem like sane behaviour since it will cause objects in a project to be compiled for the wrong target.

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.

MSVC: warning: cl : Command line warning D9002 : ignoring unknown option '/SAFESEH'

I'm building this on nightly-i686-pc-windows-msvc, and I get this warning:

warning: cl : Command line warning D9002 : ignoring unknown option '/SAFESEH'

As far as I understand, /SAFESEH is a linker flag, the compiler cl.exe doesn't understand it. It should be passed to the linker instead.

wrong default compiler for i586-pc-windows-msvc

For i586-pc-windows-msvc, gcc uses cl.exe as the compiler but for i686-pc-windows-msvc uses the full path to the compiler: C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\bin\\amd64_x86\\cl.exe. The compilation fails in the former case with "failed to execute command: The system cannot find the file specified. (os error 2)".

gcc should use the same compiler detection logic for both targets.

See these AppVeyor build jobs.

Unnecessary `if_let` feature gate causes warnings

Support executable compilation

A common configuration error when using rust-openssl is to reference headers and libraries from different versions which results in weird and hard to track down breakage. I want to handle this by compiling and running a little executable that compares the values of the version encoded in a #define in the headers and a function in the library.

Unfortunately, gcc-rs will currently only build staticlibs.

Support for building executables

I can create a pull request for this, but I wanted to discuss it first.

In some situations I find myself writing small C programs to generate Rust files with const's taken from header defines. For such it would practical to reuse gcc-rs abstractions over a C compiler.

Therefore, I propose a compile_exectuable function and to change Config::compile behavior to detect whether to build an executable or a lib based on the simple pattern, lib.so* for a library, and "not . and not lib*" for executable.

Docs aren't updating

https://travis-ci.org/alexcrichton/gcc-rs/jobs/74996514#L295

Rust <1.7 compatibility broken in #106 due to use of String::as_str

Compatibility and semver seem contentious, but I just wanted to point this out. It's a tiny change to support 1.2 so I'll send the tiny PR to do so in a bit.