#[link] attribute should better describe platform specific handling
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 45/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- documentation
Research direction
Start at the Rust Reference documentation for the #[link] attribute and compare its current platform-specific name-resolution wording with issue #62588. Document the Windows, macOS, and Linux cases, including Rust-produced library pairs, so the required name is clear for each platform.
Written by the indexing model from the issue text.
Description
When working cross platform, in particular when producing a dylib from Rust and then again consuming it, the current resolution of #[link(name = "mylib"] is somewhat confusing.
-
If you start developing on Windows, Rust will produce a
mylib.dllandmylib.dll.lib. To use this lib again from Rust you will have to specify#[link(name = "mylib.dll")], thus giving the impression that the full file name has to be specified. On Mac, however,#[link(name = "libmylib.dylib"]will fail (likewise Linux). -
If you start developing on Mac and Linux,
#[link(name = "mylib")]just works, giving you the impression Rust handles the name resolution (fully) automatically like other platforms that just require the base name.
In fact, the correct way to cross platform link against a dylib produced by Rust seems to be:
#[cfg_attr(all(target_os = "windows", target_env = "msvc"), link(name = "dylib.dll"))]
#[cfg_attr(not(all(target_os = "windows", target_env = "msvc")), link(name = "dylib"))]
extern "C" {}
Since according to this issue the current behavior can't be fixed and is "stable", I believe this should be documented somewhere. For me, the #[link] attribute was where I started my debug journey originally.
The documentation could be something like:
Note that on Mac and Linux
nameis the base name of the actual library (e.g.,#[link(name = "mylib")]if you want to link againstlibmylib.so). On Windows, the base name of the.libfile has to be provided.For 3rd party libraries such as
mylib.dllandmylib.lib, this still equals#[link(name = "mylib")], but for Rust produced library pairsmylib.dllandmylib.dll.liba#[link(name = "mylib.dll")]is needed instead.
Update - Changed #[cfg_attr] to be more correctish ...
- Dominant language
- Rust
- Stars
- 1.6k
- Forks
- 607
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 12
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rust-lang/reference
-
A-const-eval A-undefined-behavior
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
A-resolve
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
A-coercions
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
All issues in rust-lang/reference
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
kwakseongjae/auto-hwp#319 ·
-
area:cli bug filter-quality good first issue priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
bevyengine/bevy#25861 ·
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
enhancement remote
Difficulty 2/5 1-3 hours Newbie friendliness 68/100