tag | cd26c5bf8eb236fd394b4464f04dc22a8ee9271a | |
---|---|---|
tagger | David Tolnay <dtolnay@gmail.com> | Tue Aug 02 17:40:46 2022 |
object | 15c027d0e5ba21cf50c513cb679ed6e8dee213c6 |
Release 1.0.7
commit | 15c027d0e5ba21cf50c513cb679ed6e8dee213c6 | [log] [tgz] |
---|---|---|
author | David Tolnay <dtolnay@gmail.com> | Tue Aug 02 17:40:46 2022 |
committer | David Tolnay <dtolnay@gmail.com> | Tue Aug 02 17:40:46 2022 |
tree | 3aaa831d624ae61adf2586b9ac4659735ae12fc9 | |
parent | 8438f7632f8d33b5d76d84e549f05b0abb4f6c34 [diff] |
Release 1.0.7
-lstdc++
or -lc++
This crate exists for the purpose of passing -lstdc++
or -lc++
to the linker, while making it possible for an application to make that choice on behalf of its library dependencies.
Without this crate, a library would need to:
neither of which are good experiences.
An application or library that is fine with either of libstdc++ or libc++ being linked, whichever is the platform's default, should use the following in Cargo.toml:
[dependencies] link-cplusplus = "1.0"
An application that wants a particular one or the other linked should use:
[dependencies] link-cplusplus = { version = "1.0", features = ["libstdc++"] } # or link-cplusplus = { version = "1.0", features = ["libc++"] }
An application that wants to handle its own more complicated logic for link flags from its build script can make this crate do nothing by using:
[dependencies] link-cplusplus = { version = "1.0", features = ["nothing"] }
Lastly, make sure to add an explicit extern crate
dependency to your crate root, since the link-cplusplus crate will be otherwise unused and its link flags dropped.
// src/lib.rs extern crate link_cplusplus;