[hurd] Fix accessing f_type field of statvfs #71851
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
f4719c4 ("Add support for GNU Hurd in Path.inc and other places") made llvm use an internal __f_type name for the f_type field (which it is not supposed to since accessing double-underscore names is explicitly not supported by standards). In glibc 2.39 this field was renamed to f_type so application can now access the field as the standard says.
sthibaul
changed the title
|
@llvm/pr-subscribers-llvm-support Author: Samuel Thibault (sthibaul) Changesf4719c4 ("Add support for GNU Hurd in Path.inc and other places") made llvm use an internal __f_type name for the f_type field (which it is not supposed to since accessing double-underscore names is explicitly not supported by standards). In glibc 2.39 this field was renamed to f_type so application can now access the field as the standard says. Full diff: https://github.com/llvm/llvm-project/pull/71851.diff 1 Files Affected:
diff --git a/llvm/lib/Support/Unix/Path.inc b/llvm/lib/Support/Unix/Path.inc
index 68ca58fda3b8fe0..6ea0c4cac4d4def 100644
--- a/llvm/lib/Support/Unix/Path.inc
+++ b/llvm/lib/Support/Unix/Path.inc
@@ -487,7 +487,7 @@ static bool is_local_impl(struct STATVFS &Vfs) {
#ifndef CIFS_MAGIC_NUMBER
#define CIFS_MAGIC_NUMBER 0xFF534D42
#endif
-#ifdef __GNU__
+#if defined(__GNU__) && ((__GLIBC__ < 2) || ((__GLIBC__ == 2) && (__GLIBC_MINOR__ < 39)))
switch ((uint32_t)Vfs.__f_type) {
#else
switch ((uint32_t)Vfs.f_type) {
|
|
(yes, glibc 2.39 is not released yet, but we won't be going back on this, and better have llvm cope with the change before it happens) |
|
glibc 2.39 was released, with the change from the hidden |
|
Ping on this? 2.39 is in debian now, this is making llvm completely fail to build... |
|
Note sure who to ping explicitly? @espindola is apparently not active any more? Am I missing anything on this to make progress? This is a one-liner. |
|
pinging @MaskRay maybe? |
|
or perhaps @nikic @dwblaikie @sam-mccall @adrian-prantl @kazutakahirata ? |
|
Could this be backported to 19? Thanks! |
|
Is this a regression or a critical bugfix? I am only accepting really critical fixes for 19 right now. |
|
Well, it's making the build completely fail on the Hurd platform. |
Is that a regression from LLVM 18? |
No. |
|
@kazutakahirata could you merge the PR to main? I don't have write access |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/41/builds/1918 Here is the relevant piece of the build log for the reference |
|
Just to be clear, you can ignore the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
f4719c4 ("Add support for GNU Hurd in Path.inc and other places") made llvm use an internal __f_type name for the f_type field (which it is not supposed to since accessing double-underscore names is explicitly not supported by standards). In glibc 2.39 this field was renamed to f_type so application can now access the field as the standard says.