5 Feb
2017
5 Feb
'17
10:21 a.m.
On 02/05/2017 03:56, Waldemar Brodkorb wrote:
This failure is actually on o32 on a mips64 platform. I haven't tried n32 or
n64 under uclibc-ng just yet.
--
Joshua Kinard
Gentoo/MIPS
kumba(a)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
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(a)gentoo.org>rg>:
Yes, the patch is included.
For mips64 n64 please apply latest patch from master, i missed a regression while adding
aarc64 support. sorry 😐 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.
best regards
Waldemar