Re: [uclibc-ng-devel] [PATCH] 1.0.{20, 21} cannot be used in external toolchain in buildroot

[Joshua Kinard]

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 :
>>
>>> 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 
>>
>> 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 
> 

-- 
Joshua Kinard
Gentoo/MIPS
ku...@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

Re: [uclibc-ng-devel] [PATCH] 1.0.{20, 21} cannot be used in external toolchain in buildroot

[Waldemar Brodkorb]

Hi,

sorry wrong button while trying to change my sender address on iphone.

> Am 05.02.2017 um 03:29 schrieb Joshua Kinard :
> 
>> 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 
> 
> 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 
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] [PATCH] 1.0.{20, 21} cannot be used in external toolchain in buildroot

[Waldemar Brodkorb]

> Am 05.02.2017 um 03:29 schrieb Joshua Kinard :
> 
>> 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 
> 
> 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
> ku...@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

___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel