Hi,
Buildroot checks for UCLIBC_HAS_LFS feature macro, which was removed in 1.0.20 (making uClibc-ng always support large files).
Patch restores this symbol as "always-enabled".
Regards, Alexey.
On 01/23/2017 17:51, Alexey Neyman wrote:
Hi,
Buildroot checks for UCLIBC_HAS_LFS feature macro, which was removed in 1.0.20 (making uClibc-ng always support large files).
Patch restores this symbol as "always-enabled".
Regards, Alexey.
Was this picked up for 1.0.22? Lack of this option appears to burn the xfsdump package, because it forcefully looks for some kind of largefile support now:
http://oss.sgi.com/archives/xfs/2016-08/msg00265.html
So as of xfsdump-3.1.6, I can't compile it due to a failure in a configure check. This simple testcase shows what happens:
# cat x.c #include <xfs/xfs.h>
void main(void) { }
# gcc x.c -o x In file included from x.c:1:0: /usr/include/xfs/xfs.h:53:12: error: size of array 'xfs_assert_largefile' is too large extern int xfs_assert_largefile[sizeof(off_t)-8]; ^~~~~~~~~~~~~~~~~~~~
I suspect the former broke the latter, but I haven't been able to test that just yet. Or does anyone else know why xfs.h can't compile on an uclibc-ng-1.0.20 system? Platform is definitely 64-bits.
Am 05.02.2017 um 03:29 schrieb Joshua Kinard kumba@gentoo.org:
On 01/23/2017 17:51, Alexey Neyman wrote: Hi,
Buildroot checks for UCLIBC_HAS_LFS feature macro, which was removed in 1.0.20 (making uClibc-ng always support large files).
Patch restores this symbol as "always-enabled".
Regards, Alexey.
Was this picked up for 1.0.22? Lack of this option appears to burn the xfsdump package, because it forcefully looks for some kind of largefile support now:
http://oss.sgi.com/archives/xfs/2016-08/msg00265.html
So as of xfsdump-3.1.6, I can't compile it due to a failure in a configure check. This simple testcase shows what happens:
# cat x.c #include <xfs/xfs.h>
void main(void) { }
# gcc x.c -o x In file included from x.c:1:0: /usr/include/xfs/xfs.h:53:12: error: size of array 'xfs_assert_largefile' is too large extern int xfs_assert_largefile[sizeof(off_t)-8]; ^~~~~~~~~~~~~~~~~~~~
I suspect the former broke the latter, but I haven't been able to test that just yet. Or does anyone else know why xfs.h can't compile on an uclibc-ng-1.0.20 system? Platform is definitely 64-bits.
-- Joshua Kinard Gentoo/MIPS kumba@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic _______________________________________________ devel mailing list devel@uclibc-ng.org http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
Hi,
sorry wrong button while trying to change my sender address on iphone.
Am 05.02.2017 um 03:29 schrieb Joshua Kinard kumba@gentoo.org:
On 01/23/2017 17:51, Alexey Neyman wrote: Hi,
Buildroot checks for UCLIBC_HAS_LFS feature macro, which was removed in 1.0.20 (making uClibc-ng always support large files).
Patch restores this symbol as "always-enabled".
Regards, Alexey.
Was this picked up for 1.0.22?
Yes, the patch is included.
For mips64 n64 please apply latest patch from master, i missed a regression while adding aarc64 support. sorry 😐
Lack of this option appears to burn the xfsdump package, because it forcefully looks for some kind of largefile support now:
http://oss.sgi.com/archives/xfs/2016-08/msg00265.html
So as of xfsdump-3.1.6, I can't compile it due to a failure in a configure check. This simple testcase shows what happens:
# cat x.c #include <xfs/xfs.h>
void main(void) { }
# gcc x.c -o x In file included from x.c:1:0: /usr/include/xfs/xfs.h:53:12: error: size of array 'xfs_assert_largefile' is too large extern int xfs_assert_largefile[sizeof(off_t)-8]; ^~~~~~~~~~~~~~~~~~~~
I suspect the former broke the latter, but I haven't been able to test that just yet. Or does anyone else know why xfs.h can't compile on an uclibc-ng-1.0.20 system? Platform is definitely 64-bits.
best regards Waldemar
On 02/05/2017 03:56, Waldemar Brodkorb wrote:
Hi,
sorry wrong button while trying to change my sender address on iphone.
It happens :)
Am 05.02.2017 um 03:29 schrieb Joshua Kinard kumba@gentoo.org:
On 01/23/2017 17:51, Alexey Neyman wrote: Hi,
Buildroot checks for UCLIBC_HAS_LFS feature macro, which was removed in 1.0.20 (making uClibc-ng always support large files).
Patch restores this symbol as "always-enabled".
Regards, Alexey.
Was this picked up for 1.0.22?
Yes, the patch is included.
For mips64 n64 please apply latest patch from master, i missed a regression while adding aarc64 support. sorry 😐
This failure is actually on o32 on a mips64 platform. I haven't tried n32 or n64 under uclibc-ng just yet.
Lack of this option appears to burn the xfsdump package, because it forcefully looks for some kind of largefile support now:
http://oss.sgi.com/archives/xfs/2016-08/msg00265.html
So as of xfsdump-3.1.6, I can't compile it due to a failure in a configure check. This simple testcase shows what happens:
# cat x.c #include <xfs/xfs.h>
void main(void) { }
# gcc x.c -o x In file included from x.c:1:0: /usr/include/xfs/xfs.h:53:12: error: size of array 'xfs_assert_largefile' is too large extern int xfs_assert_largefile[sizeof(off_t)-8]; ^~~~~~~~~~~~~~~~~~~~
I suspect the former broke the latter, but I haven't been able to test that just yet. Or does anyone else know why xfs.h can't compile on an uclibc-ng-1.0.20 system? Platform is definitely 64-bits.
best regards Waldemar
-
Alexey Neyman -
Joshua Kinard -
Waldemar Brodkorb