tests/tcg/multiarch/linux/linux-test.c | 1 + 1 file changed, 1 insertion(+)
With newer clang builds (19.x), there's a warning for implicit function
declarations and it rejects linux-test.c.
glibc/musl's readdir64() declaration in dirent is guarded by
_LARGEFILE64_SOURCE, so we'll define it to fix the warning.
BUILD hexagon-linux-user guest-tests
/local/mnt/workspace/upstream/toolchain_for_hexagon/qemu/tests/tcg/multiarch/linux/linux-test.c:189:14: error: call to undeclared function 'readdir64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
189 | de = readdir64(dir);
| ^
Signed-off-by: Brian Cain <bcain@quicinc.com>
---
tests/tcg/multiarch/linux/linux-test.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/tcg/multiarch/linux/linux-test.c b/tests/tcg/multiarch/linux/linux-test.c
index 64f57cb287..4e0e862ad9 100644
--- a/tests/tcg/multiarch/linux/linux-test.c
+++ b/tests/tcg/multiarch/linux/linux-test.c
@@ -17,6 +17,7 @@
* along with this program; if not, see <http://www.gnu.org/licenses/>.
*/
#define _GNU_SOURCE
+#define _LARGEFILE64_SOURCE
#include <stdarg.h>
#include <stdlib.h>
#include <stdio.h>
--
2.34.1On 9/6/2024 9:39 PM, Brian Cain wrote: > With newer clang builds (19.x), there's a warning for implicit function > declarations and it rejects linux-test.c. > > glibc/musl's readdir64() declaration in dirent is guarded by > _LARGEFILE64_SOURCE, so we'll define it to fix the warning. > > BUILD hexagon-linux-user guest-tests > /local/mnt/workspace/upstream/toolchain_for_hexagon/qemu/tests/tcg/multiarch/linux/linux-test.c:189:14: error: call to undeclared function 'readdir64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > 189 | de = readdir64(dir); > | ^ > > Signed-off-by: Brian Cain <bcain@quicinc.com> > --- > tests/tcg/multiarch/linux/linux-test.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/tcg/multiarch/linux/linux-test.c b/tests/tcg/multiarch/linux/linux-test.c > index 64f57cb287..4e0e862ad9 100644 > --- a/tests/tcg/multiarch/linux/linux-test.c > +++ b/tests/tcg/multiarch/linux/linux-test.c > @@ -17,6 +17,7 @@ > * along with this program; if not, see <http://www.gnu.org/licenses/>. > */ > #define _GNU_SOURCE > +#define _LARGEFILE64_SOURCE > #include <stdarg.h> > #include <stdlib.h> > #include <stdio.h> Alex -- what do you think about this one?
Brian Cain <quic_bcain@quicinc.com> writes: > On 9/6/2024 9:39 PM, Brian Cain wrote: >> With newer clang builds (19.x), there's a warning for implicit function >> declarations and it rejects linux-test.c. >> >> glibc/musl's readdir64() declaration in dirent is guarded by >> _LARGEFILE64_SOURCE, so we'll define it to fix the warning. >> >> BUILD hexagon-linux-user guest-tests >> /local/mnt/workspace/upstream/toolchain_for_hexagon/qemu/tests/tcg/multiarch/linux/linux-test.c:189:14: error: call to undeclared function 'readdir64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] >> 189 | de = readdir64(dir); >> | ^ >> >> Signed-off-by: Brian Cain <bcain@quicinc.com> >> --- >> tests/tcg/multiarch/linux/linux-test.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/tests/tcg/multiarch/linux/linux-test.c b/tests/tcg/multiarch/linux/linux-test.c >> index 64f57cb287..4e0e862ad9 100644 >> --- a/tests/tcg/multiarch/linux/linux-test.c >> +++ b/tests/tcg/multiarch/linux/linux-test.c >> @@ -17,6 +17,7 @@ >> * along with this program; if not, see <http://www.gnu.org/licenses/>. >> */ >> #define _GNU_SOURCE >> +#define _LARGEFILE64_SOURCE >> #include <stdarg.h> >> #include <stdlib.h> >> #include <stdio.h> > > > Alex -- what do you think about this one? Actually scratch that, this is a 32 compat hack: 1f442da51e (tests/tcg/multiarch: fix 32bit linux-test on 64bit host) Is the __USE_LARGEFILE64 symbol in the hexagon headers? -- Alex Bennée Virtualisation Tech Lead @ Linaro
On 9/16/2024 8:12 AM, Alex Bennée wrote: > Brian Cain <quic_bcain@quicinc.com> writes: > >> On 9/6/2024 9:39 PM, Brian Cain wrote: >>> With newer clang builds (19.x), there's a warning for implicit function >>> declarations and it rejects linux-test.c. >>> >>> glibc/musl's readdir64() declaration in dirent is guarded by >>> _LARGEFILE64_SOURCE, so we'll define it to fix the warning. >>> >>> BUILD hexagon-linux-user guest-tests >>> /local/mnt/workspace/upstream/toolchain_for_hexagon/qemu/tests/tcg/multiarch/linux/linux-test.c:189:14: error: call to undeclared function 'readdir64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] >>> 189 | de = readdir64(dir); >>> | ^ >>> >>> Signed-off-by: Brian Cain <bcain@quicinc.com> >>> --- >>> tests/tcg/multiarch/linux/linux-test.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/tests/tcg/multiarch/linux/linux-test.c b/tests/tcg/multiarch/linux/linux-test.c >>> index 64f57cb287..4e0e862ad9 100644 >>> --- a/tests/tcg/multiarch/linux/linux-test.c >>> +++ b/tests/tcg/multiarch/linux/linux-test.c >>> @@ -17,6 +17,7 @@ >>> * along with this program; if not, see <http://www.gnu.org/licenses/>. >>> */ >>> #define _GNU_SOURCE >>> +#define _LARGEFILE64_SOURCE >>> #include <stdarg.h> >>> #include <stdlib.h> >>> #include <stdio.h> >> >> Alex -- what do you think about this one? > Actually scratch that, this is a 32 compat hack: > > 1f442da51e (tests/tcg/multiarch: fix 32bit linux-test on 64bit host) > > Is the __USE_LARGEFILE64 symbol in the hexagon headers? > musl does not define/use __USE_LARGEFILE64, no. If it's well defined I could examine whether it makes sense to add this feature to musl, though. How does __USE_LARGEFILE64 differ from _LARGEFILE64_SOURCE? Is it more appropriate to define that here? -Brian
Brian Cain <quic_bcain@quicinc.com> writes: > On 9/16/2024 8:12 AM, Alex Bennée wrote: >> Brian Cain <quic_bcain@quicinc.com> writes: >> >>> On 9/6/2024 9:39 PM, Brian Cain wrote: >>>> With newer clang builds (19.x), there's a warning for implicit function >>>> declarations and it rejects linux-test.c. >>>> >>>> glibc/musl's readdir64() declaration in dirent is guarded by >>>> _LARGEFILE64_SOURCE, so we'll define it to fix the warning. >>>> >>>> BUILD hexagon-linux-user guest-tests >>>> /local/mnt/workspace/upstream/toolchain_for_hexagon/qemu/tests/tcg/multiarch/linux/linux-test.c:189:14: error: call to undeclared function 'readdir64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] >>>> 189 | de = readdir64(dir); >>>> | ^ >>>> >>>> Signed-off-by: Brian Cain <bcain@quicinc.com> >>>> --- >>>> tests/tcg/multiarch/linux/linux-test.c | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/tests/tcg/multiarch/linux/linux-test.c b/tests/tcg/multiarch/linux/linux-test.c >>>> index 64f57cb287..4e0e862ad9 100644 >>>> --- a/tests/tcg/multiarch/linux/linux-test.c >>>> +++ b/tests/tcg/multiarch/linux/linux-test.c >>>> @@ -17,6 +17,7 @@ >>>> * along with this program; if not, see <http://www.gnu.org/licenses/>. >>>> */ >>>> #define _GNU_SOURCE >>>> +#define _LARGEFILE64_SOURCE >>>> #include <stdarg.h> >>>> #include <stdlib.h> >>>> #include <stdio.h> >>> >>> Alex -- what do you think about this one? >> Actually scratch that, this is a 32 compat hack: >> >> 1f442da51e (tests/tcg/multiarch: fix 32bit linux-test on 64bit host) >> >> Is the __USE_LARGEFILE64 symbol in the hexagon headers? >> > musl does not define/use __USE_LARGEFILE64, no. If it's well defined > I could examine whether it makes sense to add this feature to musl, > though. How does __USE_LARGEFILE64 differ from _LARGEFILE64_SOURCE? > Is it more appropriate to define that here? Digging into the GNU source _LARGEFILE* is the correct define, the __USE flags are internal. features.h says: _LARGEFILE_SOURCE Some more functions for correct standard I/O. _LARGEFILE64_SOURCE Additional functionality from LFS for large files. although looking at _LARGEFILE64_SOURCE should be defined by _GNU_SOURCE which is already set for linux-test.c According to the musl WHATSNEW: compatibility: - make _GNU_SOURCE imply _LARGEFILE64_SOURCE So is this a hexagon only thing? > > -Brian -- Alex Bennée Virtualisation Tech Lead @ Linaro
On 9/16/2024 10:47 AM, Alex Bennée wrote: > Brian Cain <quic_bcain@quicinc.com> writes: > >> On 9/16/2024 8:12 AM, Alex Bennée wrote: >>> Brian Cain <quic_bcain@quicinc.com> writes: >>> >>>> On 9/6/2024 9:39 PM, Brian Cain wrote: >>>>> With newer clang builds (19.x), there's a warning for implicit function >>>>> declarations and it rejects linux-test.c. >>>>> >>>>> glibc/musl's readdir64() declaration in dirent is guarded by >>>>> _LARGEFILE64_SOURCE, so we'll define it to fix the warning. >>>>> >>>>> BUILD hexagon-linux-user guest-tests >>>>> /local/mnt/workspace/upstream/toolchain_for_hexagon/qemu/tests/tcg/multiarch/linux/linux-test.c:189:14: error: call to undeclared function 'readdir64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] >>>>> 189 | de = readdir64(dir); >>>>> | ^ >>>>> >>>>> Signed-off-by: Brian Cain <bcain@quicinc.com> >>>>> --- >>>>> tests/tcg/multiarch/linux/linux-test.c | 1 + >>>>> 1 file changed, 1 insertion(+) >>>>> >>>>> diff --git a/tests/tcg/multiarch/linux/linux-test.c b/tests/tcg/multiarch/linux/linux-test.c >>>>> index 64f57cb287..4e0e862ad9 100644 >>>>> --- a/tests/tcg/multiarch/linux/linux-test.c >>>>> +++ b/tests/tcg/multiarch/linux/linux-test.c >>>>> @@ -17,6 +17,7 @@ >>>>> * along with this program; if not, see <http://www.gnu.org/licenses/>. >>>>> */ >>>>> #define _GNU_SOURCE >>>>> +#define _LARGEFILE64_SOURCE >>>>> #include <stdarg.h> >>>>> #include <stdlib.h> >>>>> #include <stdio.h> >>>> Alex -- what do you think about this one? >>> Actually scratch that, this is a 32 compat hack: >>> >>> 1f442da51e (tests/tcg/multiarch: fix 32bit linux-test on 64bit host) >>> >>> Is the __USE_LARGEFILE64 symbol in the hexagon headers? >>> >> musl does not define/use __USE_LARGEFILE64, no. If it's well defined >> I could examine whether it makes sense to add this feature to musl, >> though. How does __USE_LARGEFILE64 differ from _LARGEFILE64_SOURCE? >> Is it more appropriate to define that here? > Digging into the GNU source _LARGEFILE* is the correct define, the __USE > flags are internal. features.h says: > > _LARGEFILE_SOURCE Some more functions for correct standard I/O. > _LARGEFILE64_SOURCE Additional functionality from LFS for large files. > > although looking at _LARGEFILE64_SOURCE should be defined by > _GNU_SOURCE which is already set for linux-test.c > > According to the musl WHATSNEW: > > compatibility: > - make _GNU_SOURCE imply _LARGEFILE64_SOURCE Yeah, I just noticed that myself. I guess I will look at how it's done and see if I can fix this so it's more general and can include this case. > So is this a hexagon only thing? It's not - I expect it would impact any architecture using musl. >> -Brian
On 9/16/2024 11:05 AM, Brian Cain wrote: > > On 9/16/2024 10:47 AM, Alex Bennée wrote: >> Brian Cain <quic_bcain@quicinc.com> writes: >> >>> On 9/16/2024 8:12 AM, Alex Bennée wrote: >>>> Brian Cain <quic_bcain@quicinc.com> writes: >>>> >>>>> On 9/6/2024 9:39 PM, Brian Cain wrote: >>>>>> With newer clang builds (19.x), there's a warning for implicit >>>>>> function >>>>>> declarations and it rejects linux-test.c. >>>>>> >>>>>> glibc/musl's readdir64() declaration in dirent is guarded by >>>>>> _LARGEFILE64_SOURCE, so we'll define it to fix the warning. >>>>>> >>>>>> BUILD hexagon-linux-user guest-tests >>>>>> /local/mnt/workspace/upstream/toolchain_for_hexagon/qemu/tests/tcg/multiarch/linux/linux-test.c:189:14: >>>>>> error: call to undeclared function 'readdir64'; ISO C99 and later >>>>>> do not support implicit function declarations >>>>>> [-Wimplicit-function-declaration] >>>>>> 189 | de = readdir64(dir); >>>>>> | ^ >>>>>> >>>>>> Signed-off-by: Brian Cain <bcain@quicinc.com> >>>>>> --- >>>>>> tests/tcg/multiarch/linux/linux-test.c | 1 + >>>>>> 1 file changed, 1 insertion(+) >>>>>> >>>>>> diff --git a/tests/tcg/multiarch/linux/linux-test.c >>>>>> b/tests/tcg/multiarch/linux/linux-test.c >>>>>> index 64f57cb287..4e0e862ad9 100644 >>>>>> --- a/tests/tcg/multiarch/linux/linux-test.c >>>>>> +++ b/tests/tcg/multiarch/linux/linux-test.c >>>>>> @@ -17,6 +17,7 @@ >>>>>> * along with this program; if not, see >>>>>> <http://www.gnu.org/licenses/>. >>>>>> */ >>>>>> #define _GNU_SOURCE >>>>>> +#define _LARGEFILE64_SOURCE >>>>>> #include <stdarg.h> >>>>>> #include <stdlib.h> >>>>>> #include <stdio.h> >>>>> Alex -- what do you think about this one? >>>> Actually scratch that, this is a 32 compat hack: >>>> >>>> 1f442da51e (tests/tcg/multiarch: fix 32bit linux-test on 64bit >>>> host) >>>> >>>> Is the __USE_LARGEFILE64 symbol in the hexagon headers? >>>> >>> musl does not define/use __USE_LARGEFILE64, no. If it's well defined >>> I could examine whether it makes sense to add this feature to musl, >>> though. How does __USE_LARGEFILE64 differ from _LARGEFILE64_SOURCE? >>> Is it more appropriate to define that here? >> Digging into the GNU source _LARGEFILE* is the correct define, the __USE >> flags are internal. features.h says: >> >> _LARGEFILE_SOURCE Some more functions for correct standard I/O. >> _LARGEFILE64_SOURCE Additional functionality from LFS for large >> files. >> >> although looking at _LARGEFILE64_SOURCE should be defined by >> _GNU_SOURCE which is already set for linux-test.c >> >> According to the musl WHATSNEW: >> >> compatibility: >> - make _GNU_SOURCE imply _LARGEFILE64_SOURCE > > Yeah, I just noticed that myself. I guess I will look at how it's done > and see if I can fix this so it's more general and can include this case. > >> So is this a hexagon only thing? > It's not - I expect it would impact any architecture using musl. > Hmm. The _GNU_SOURCE guard was deliberately removed in 25e6fee27f4a293728dd15b659170e7b9c7db9bc (see below). IMO the relevant text is "portable software should be prepared for them not to exist" and " the intent is that this be a very short-term measure and that the macros be removed entirely in the next release cycle." They're still there, guarded by only _LARGEFILE64_SOURCE. I will bring up the question about what the future plan for this is on the musl list, but I also think that the appropriate, portable thing to do is to change the test case regardless of musl's plans. If there were some other conformant C library it could implement it the same way. IIUC the relevant specification is here https://unix.org/version2/whatsnew/lfs20mar.html commit 25e6fee27f4a293728dd15b659170e7b9c7db9bc Author: Rich Felker <dalias@aerifal.cx> Date: Tue Sep 27 15:04:05 2022 -0400 remove LFS64 programming interfaces (macro-only) from _GNU_SOURCE these badly pollute the namespace with macros whenever _GNU_SOURCE is defined, which is always the case with g++, and especially tends to interfere with C++ constructs. as our implementation of these was macro-only, their removal cannot affect any existing binaries. at the source level, portable software should be prepared for them not to exist. for now, they are left in place with explicit _LARGEFILE64_SOURCE. this provides an easy temporary path for integrators/distributions to get packages building again right away if they break while working on a proper, upstreamable fix. the intent is that this be a very short-term measure and that the macros be removed entirely in the next release cycle.
On 9/16/2024 11:31 AM, Brian Cain wrote: > > On 9/16/2024 11:05 AM, Brian Cain wrote: >> >> On 9/16/2024 10:47 AM, Alex Bennée wrote: >>> Brian Cain <quic_bcain@quicinc.com> writes: >>> >>>> On 9/16/2024 8:12 AM, Alex Bennée wrote: >>>>> Brian Cain <quic_bcain@quicinc.com> writes: >>>>> >>>>>> On 9/6/2024 9:39 PM, Brian Cain wrote: >>>>>>> With newer clang builds (19.x), there's a warning for implicit >>>>>>> function >>>>>>> declarations and it rejects linux-test.c. >>>>>>> >>>>>>> glibc/musl's readdir64() declaration in dirent is guarded by >>>>>>> _LARGEFILE64_SOURCE, so we'll define it to fix the warning. >>>>>>> >>>>>>> BUILD hexagon-linux-user guest-tests >>>>>>> /local/mnt/workspace/upstream/toolchain_for_hexagon/qemu/tests/tcg/multiarch/linux/linux-test.c:189:14: >>>>>>> error: call to undeclared function 'readdir64'; ISO C99 and >>>>>>> later do not support implicit function declarations >>>>>>> [-Wimplicit-function-declaration] >>>>>>> 189 | de = readdir64(dir); >>>>>>> | ^ >>>>>>> >>>>>>> Signed-off-by: Brian Cain <bcain@quicinc.com> >>>>>>> --- >>>>>>> tests/tcg/multiarch/linux/linux-test.c | 1 + >>>>>>> 1 file changed, 1 insertion(+) >>>>>>> >>>>>>> diff --git a/tests/tcg/multiarch/linux/linux-test.c >>>>>>> b/tests/tcg/multiarch/linux/linux-test.c >>>>>>> index 64f57cb287..4e0e862ad9 100644 >>>>>>> --- a/tests/tcg/multiarch/linux/linux-test.c >>>>>>> +++ b/tests/tcg/multiarch/linux/linux-test.c >>>>>>> @@ -17,6 +17,7 @@ >>>>>>> * along with this program; if not, see >>>>>>> <http://www.gnu.org/licenses/>. >>>>>>> */ >>>>>>> #define _GNU_SOURCE >>>>>>> +#define _LARGEFILE64_SOURCE >>>>>>> #include <stdarg.h> >>>>>>> #include <stdlib.h> >>>>>>> #include <stdio.h> >>>>>> Alex -- what do you think about this one? >>>>> Actually scratch that, this is a 32 compat hack: >>>>> >>>>> 1f442da51e (tests/tcg/multiarch: fix 32bit linux-test on 64bit >>>>> host) >>>>> >>>>> Is the __USE_LARGEFILE64 symbol in the hexagon headers? >>>>> >>>> musl does not define/use __USE_LARGEFILE64, no. If it's well defined >>>> I could examine whether it makes sense to add this feature to musl, >>>> though. How does __USE_LARGEFILE64 differ from _LARGEFILE64_SOURCE? >>>> Is it more appropriate to define that here? >>> Digging into the GNU source _LARGEFILE* is the correct define, the >>> __USE >>> flags are internal. features.h says: >>> >>> _LARGEFILE_SOURCE Some more functions for correct standard I/O. >>> _LARGEFILE64_SOURCE Additional functionality from LFS for large >>> files. >>> >>> although looking at _LARGEFILE64_SOURCE should be defined by >>> _GNU_SOURCE which is already set for linux-test.c >>> >>> According to the musl WHATSNEW: >>> >>> compatibility: >>> - make _GNU_SOURCE imply _LARGEFILE64_SOURCE >> >> Yeah, I just noticed that myself. I guess I will look at how it's >> done and see if I can fix this so it's more general and can include >> this case. >> >>> So is this a hexagon only thing? >> It's not - I expect it would impact any architecture using musl. >> > > Hmm. The _GNU_SOURCE guard was deliberately removed in > 25e6fee27f4a293728dd15b659170e7b9c7db9bc (see below). IMO the > relevant text is "portable software should be prepared for them not to > exist" and " the intent is that this be a very short-term measure and > that the macros be removed entirely in the next release cycle." > They're still there, guarded by only _LARGEFILE64_SOURCE. I will > bring up the question about what the future plan for this is on the > musl list, but I also think that the appropriate, portable thing to do > is to change the test case regardless of musl's plans. If there were > some other conformant C library it could implement it the same way. > IIUC the relevant specification is here > https://unix.org/version2/whatsnew/lfs20mar.html > > After discussion on the musl list, the suggestion was to use _FILE_OFFSET_BITS to get portable behavior without relying on non-POSIX LFS64: https://www.openwall.com/lists/musl/2024/09/18/5 I'll test this suggestion out and send a new patch. -Brian
Brian Cain <quic_bcain@quicinc.com> writes:
> On 9/6/2024 9:39 PM, Brian Cain wrote:
>> With newer clang builds (19.x), there's a warning for implicit function
>> declarations and it rejects linux-test.c.
>>
>> glibc/musl's readdir64() declaration in dirent is guarded by
>> _LARGEFILE64_SOURCE, so we'll define it to fix the warning.
>>
>> BUILD hexagon-linux-user guest-tests
>> /local/mnt/workspace/upstream/toolchain_for_hexagon/qemu/tests/tcg/multiarch/linux/linux-test.c:189:14: error: call to undeclared function 'readdir64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
>> 189 | de = readdir64(dir);
>> | ^
>>
>> Signed-off-by: Brian Cain <bcain@quicinc.com>
>> ---
>> tests/tcg/multiarch/linux/linux-test.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/tests/tcg/multiarch/linux/linux-test.c b/tests/tcg/multiarch/linux/linux-test.c
>> index 64f57cb287..4e0e862ad9 100644
>> --- a/tests/tcg/multiarch/linux/linux-test.c
>> +++ b/tests/tcg/multiarch/linux/linux-test.c
>> @@ -17,6 +17,7 @@
>> * along with this program; if not, see <http://www.gnu.org/licenses/>.
>> */
>> #define _GNU_SOURCE
>> +#define _LARGEFILE64_SOURCE
>> #include <stdarg.h>
>> #include <stdlib.h>
>> #include <stdio.h>
>
>
> Alex -- what do you think about this one?
Looking at the glibc headers the LARGEFILE stuff seems to be mainly
about cleanly mapping readdir64 to readdir. I don't think we are trying
to exercise 64 on 32 here so we could do:
modified tests/tcg/multiarch/linux/linux-test.c
@@ -83,7 +83,7 @@ static void test_file(void)
struct utimbuf tbuf;
struct iovec vecs[2];
DIR *dir;
- struct dirent64 *de;
+ struct dirent *de;
/* TODO: make common tempdir creation for tcg tests */
char template[] = "/tmp/linux-test-XXXXXX";
char *tmpdir = mkdtemp(template);
@@ -186,7 +186,7 @@ static void test_file(void)
error("opendir");
len = 0;
for(;;) {
- de = readdir64(dir);
+ de = readdir(dir);
if (!de)
break;
if (strcmp(de->d_name, ".") != 0 &&
Does that work for your clang case?
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
© 2016 - 2024 Red Hat, Inc.