Skip to content

Conversation

@behlendorf
Copy link
Contributor

Motivation and Context

#16636

Description

Some C libraries, such as uClibc, do not provide strerror_l() in which case we fallback to strerror().

How Has This Been Tested?

@jlsalvador would you mind testing this in your environment.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
  • Documentation (a change to man pages or other documentation)

@behlendorf behlendorf added Type: Building Indicates an issue related to building binaries Status: Code Review Needed Ready for review and testing labels Oct 11, 2024
@jlsalvador
Copy link
Contributor

How Has This Been Tested?

@jlsalvador would you mind testing this in your environment.

It works correctly using glibc v13.3.0, musl v1.2.5, and uclibc v1.0.50.
Thank you @behlendorf! 👍

Tested-by: José Luis Salvador Rufo [email protected]

Some C libraries, such as uClibc, do not provide strerror_l() in
which case we fallback to strerror().

Signed-off-by: Brian Behlendorf <[email protected]>
@behlendorf behlendorf added Status: Accepted Ready to integrate (reviewed, tested) and removed Status: Code Review Needed Ready for review and testing labels Oct 11, 2024
@behlendorf behlendorf merged commit 48dfe39 into openzfs:master Oct 12, 2024
18 of 20 checks passed
behlendorf added a commit to behlendorf/zfs that referenced this pull request Oct 14, 2024
Some C libraries, such as uClibc, do not provide strerror_l() in
which case we fallback to strerror().

Reviewed-by: Tino Reichardt <[email protected]>
Signed-off-by: Brian Behlendorf <[email protected]>
Closes openzfs#16636 
Closes openzfs#16640
ptr1337 pushed a commit to CachyOS/zfs that referenced this pull request Nov 14, 2024
Some C libraries, such as uClibc, do not provide strerror_l() in
which case we fallback to strerror().

Reviewed-by: Tino Reichardt <[email protected]>
Signed-off-by: Brian Behlendorf <[email protected]>
Closes openzfs#16636 
Closes openzfs#16640
rkojedzinszky added a commit to rkojedzinszky/zfs that referenced this pull request Jan 3, 2025
rkojedzinszky added a commit to rkojedzinszky/zfs that referenced this pull request Jan 3, 2025
rkojedzinszky added a commit to rkojedzinszky/zfs that referenced this pull request Jan 3, 2025
rkojedzinszky added a commit to rkojedzinszky/zfs that referenced this pull request Jan 3, 2025
behlendorf pushed a commit that referenced this pull request Jan 4, 2025
#15793 wanted to make zfs_strerror threadsafe, unfortunately, it
turned out that strerror_l() usage was wrong, and also, some libc 
implementations dont have strerror_l().

zfs_strerror() now simply calls original strerror() and copies the 
result to a thread-local buffer, then returns that.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Richard Kojedzinszky <[email protected]>
Closes #15793
Closes #16640
Closes #16923
behlendorf pushed a commit to behlendorf/zfs that referenced this pull request Jan 4, 2025
openzfs#15793 wanted to make zfs_strerror threadsafe, unfortunately, it
turned out that strerror_l() usage was wrong, and also, some libc 
implementations dont have strerror_l().

zfs_strerror() now simply calls original strerror() and copies the 
result to a thread-local buffer, then returns that.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Richard Kojedzinszky <[email protected]>
Closes openzfs#15793
Closes openzfs#16640
Closes openzfs#16923
rkojedzinszky added a commit to dravanet/openzfs-zfs that referenced this pull request Jan 5, 2025
openzfs#15793 wanted to make zfs_strerror threadsafe, unfortunately, it
turned out that strerror_l() usage was wrong, and also, some libc 
implementations dont have strerror_l().

zfs_strerror() now simply calls original strerror() and copies the 
result to a thread-local buffer, then returns that.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Richard Kojedzinszky <[email protected]>
Closes openzfs#15793
Closes openzfs#16640
Closes openzfs#16923
rkojedzinszky added a commit to dravanet/openzfs-zfs that referenced this pull request Jan 6, 2025
turned out that strerror_l() usage was wrong, and also, some libc
implementations dont have strerror_l().

zfs_strerror() now simply calls original strerror() and copies the
result to a thread-local buffer, then returns that.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Richard Kojedzinszky <[email protected]>
Closes openzfs#15793
Closes openzfs#16640
Closes openzfs#16923

Upstream commit dc0324b
lundman pushed a commit to openzfsonwindows/openzfs that referenced this pull request Jan 26, 2025
Some C libraries, such as uClibc, do not provide strerror_l() in
which case we fallback to strerror().

Reviewed-by: Tino Reichardt <[email protected]>
Signed-off-by: Brian Behlendorf <[email protected]>
Closes openzfs#16636 
Closes openzfs#16640
lundman pushed a commit to openzfsonwindows/openzfs that referenced this pull request Jan 26, 2025
openzfs#15793 wanted to make zfs_strerror threadsafe, unfortunately, it
turned out that strerror_l() usage was wrong, and also, some libc 
implementations dont have strerror_l().

zfs_strerror() now simply calls original strerror() and copies the 
result to a thread-local buffer, then returns that.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Richard Kojedzinszky <[email protected]>
Closes openzfs#15793
Closes openzfs#16640
Closes openzfs#16923
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Status: Accepted Ready to integrate (reviewed, tested) Type: Building Indicates an issue related to building binaries

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants