| Message ID | ba4e750b-c3ea-8514-8563-caa216049ad5@att.net |
|---|---|
| State | Accepted |
| Headers | show |
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 >
From 2a40d18badc4f0bff8c2e02507cd8d59cfeb3e7c Mon Sep 17 00:00:00 2001 From: Alexey Neyman <stilor@att.net> Date: Mon, 23 Jan 2017 14:21:54 -0800 Subject: [PATCH] Restore UCLIBC_HAS_LFS as "always enabled". Otherwise, buildroot rejects uClibc-ng in an external toolchain. Signed-off-by: Alexey Neyman <stilor@att.net> --- extra/Configs/Config.in | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/extra/Configs/Config.in b/extra/Configs/Config.in index a9d62f5..b2cf977 100644 --- a/extra/Configs/Config.in +++ b/extra/Configs/Config.in @@ -566,6 +566,11 @@ config UCLIBC_HAS_SYSLOG Support sending messages to the system logger. This requires socket-support. +config UCLIBC_HAS_LFS + def_bool y + help + Large file support (always enabled; config symbol retained for + feature test to be compatible with uClibc). choice prompt "Malloc Implementation" default MALLOC if ! ARCH_USE_MMU -- 2.9.3