Skip to content

Commit dc38d87

Browse files
Fix linker error
This makes `fs::hard_link` use weak! for some platforms, thereby preventing a linker error.
1 parent 8eae2eb commit dc38d87

File tree

1 file changed

+30
-11
lines changed
  • library/std/src/sys/unix

1 file changed

+30
-11
lines changed

library/std/src/sys/unix/fs.rs

+30-11
Original file line numberDiff line numberDiff line change
@@ -14,6 +14,12 @@ use crate::sys_common::{AsInner, FromInner};
1414

1515
use libc::{c_int, mode_t};
1616

17+
#[cfg(any(
18+
target_os = "macos",
19+
target_os = "ios",
20+
all(target_os = "linux", target_env = "gnu")
21+
))]
22+
use libc::c_char;
1723
#[cfg(any(target_os = "linux", target_os = "emscripten", target_os = "android"))]
1824
use libc::dirfd;
1925
#[cfg(any(target_os = "linux", target_os = "emscripten"))]
@@ -92,7 +98,7 @@ cfg_has_statx! {{
9298
// Default `stat64` contains no creation time.
9399
unsafe fn try_statx(
94100
fd: c_int,
95-
path: *const libc::c_char,
101+
path: *const c_char,
96102
flags: i32,
97103
mask: u32,
98104
) -> Option<io::Result<FileAttr>> {
@@ -107,7 +113,7 @@ cfg_has_statx! {{
107113
syscall! {
108114
fn statx(
109115
fd: c_int,
110-
pathname: *const libc::c_char,
116+
pathname: *const c_char,
111117
flags: c_int,
112118
mask: libc::c_uint,
113119
statxbuf: *mut libc::statx
@@ -756,7 +762,7 @@ impl File {
756762
cfg_has_statx! {
757763
if let Some(ret) = unsafe { try_statx(
758764
fd,
759-
b"\0" as *const _ as *const libc::c_char,
765+
b"\0" as *const _ as *const c_char,
760766
libc::AT_EMPTY_PATH | libc::AT_STATX_SYNC_AS_STAT,
761767
libc::STATX_ALL,
762768
) } {
@@ -1087,15 +1093,28 @@ pub fn link(original: &Path, link: &Path) -> io::Result<()> {
10871093
let link = cstr(link)?;
10881094
cfg_if::cfg_if! {
10891095
if #[cfg(any(target_os = "vxworks", target_os = "redox", target_os = "android"))] {
1090-
// VxWorks, Redox, and old versions of Android lack `linkat`, so use
1091-
// `link` instead. POSIX leaves it implementation-defined whether
1092-
// `link` follows symlinks, so rely on the `symlink_hard_link` test
1093-
// in library/std/src/fs/tests.rs to check the behavior.
1096+
// VxWorks and Redox lack `linkat`, so use `link` instead. POSIX leaves
1097+
// it implementation-defined whether `link` follows symlinks, so rely on the
1098+
// `symlink_hard_link` test in library/std/src/fs/tests.rs to check the behavior.
1099+
// Android has `linkat` on newer versions, but we happen to know `link`
1100+
// always has the correct behavior, so it's here as well.
10941101
cvt(unsafe { libc::link(original.as_ptr(), link.as_ptr()) })?;
1102+
} else if #[cfg(target_os = "macos")] {
1103+
// On MacOS, older versions (<=10.9) lack support for linkat while newer
1104+
// versions have it. We want to use linkat if it is available, so we use weak!
1105+
// to check. `linkat` is preferable to `link` ecause it gives us a flag to
1106+
// specify how symlinks should be handled. We pass 0 as the flags argument,
1107+
// meaning it shouldn't follow symlinks.
1108+
weak!(fn linkat(c_int, *const c_char, c_int, *const c_char, c_int) -> c_int);
1109+
1110+
if let Some(f) = linkat.get() {
1111+
cvt(unsafe { f(libc::AT_FDCWD, original.as_ptr(), libc::AT_FDCWD, link.as_ptr(), 0) })?;
1112+
} else {
1113+
cvt(unsafe { libc::link(original.as_ptr(), link.as_ptr()) })?;
1114+
};
10951115
} else {
1096-
// Use `linkat` with `AT_FDCWD` instead of `link` as `linkat` gives
1097-
// us a flag to specify how symlinks should be handled. Pass 0 as
1098-
// the flags argument, meaning don't follow symlinks.
1116+
// Where we can, use `linkat` instead of `link`; see the comment above
1117+
// this one for details on why.
10991118
cvt(unsafe { libc::linkat(libc::AT_FDCWD, original.as_ptr(), libc::AT_FDCWD, link.as_ptr(), 0) })?;
11001119
}
11011120
}
@@ -1278,7 +1297,7 @@ pub fn copy(from: &Path, to: &Path) -> io::Result<u64> {
12781297
fn fclonefileat(
12791298
srcfd: libc::c_int,
12801299
dst_dirfd: libc::c_int,
1281-
dst: *const libc::c_char,
1300+
dst: *const c_char,
12821301
flags: libc::c_int
12831302
) -> libc::c_int
12841303
}

0 commit comments

Comments
 (0)