Re: [uclibc-ng-devel] preparing for release

2016-11-30 Thread Thomas Petazzoni
Hello,

On Tue, 29 Nov 2016 21:43:20 -0800, Vineet Gupta wrote:

> On 11/29/2016 09:31 PM, Waldemar Brodkorb wrote:
> > Hi,
> >
> > I am preparing a release and would like to remove UCLIBC_HAS_LFS
> > before doing it.
> >
> > I believe UCLIBC_HAS_LFS does make the code more complex and
> > the benefit to disable it to save some bytes is not high enough.
> >
> > Most users have UCLIBC_HAS_LFS enabled and it is enabled by default.
> >
> > Attached is a patch.
> >
> > Any comments?
> >
> > best regards
> >  Waldemar  
> 
> I welcome this change - is there going to be impact on downstream projects 
> like
> busybox. What if it some disables CONFIG_LFS inside busybox ?

In Buildroot, we have dropped the ability to disable LFS since March
2015. It was really too annoying to maintain the !LFS case, for no real
benefit.

So I'm completely fine with uClibc-ng dropping !LFS support upstream,
since Buildroot no longer cares about this possibility.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel


Re: [uclibc-ng-devel] preparing for release

2016-11-30 Thread Alexey Brodkin
Opps, didn't notice Vineet has already answered :)

-Alexey

On Wed, 2016-11-30 at 12:25 +0300, Alexey Brodkin wrote:
> Hi Waldemar,
> 
> On Wed, 2016-11-30 at 06:31 +0100, Waldemar Brodkorb wrote:
> > 
> > Hi,
> > 
> > I am preparing a release and would like to remove UCLIBC_HAS_LFS
> > before doing it.
> > 
> > I believe UCLIBC_HAS_LFS does make the code more complex and
> > the benefit to disable it to save some bytes is not high enough.
> > 
> > Most users have UCLIBC_HAS_LFS enabled and it is enabled by default.
> > 
> > Attached is a patch.
> > 
> > Any comments?
> 
> Looks good to me, thought maybe Vineet has another opinion on that.
> 
> -Alexey
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel


Re: [uclibc-ng-devel] preparing for release

2016-11-30 Thread Alexey Brodkin
Hi Waldemar,

On Wed, 2016-11-30 at 06:31 +0100, Waldemar Brodkorb wrote:
> Hi,
> 
> I am preparing a release and would like to remove UCLIBC_HAS_LFS
> before doing it.
> 
> I believe UCLIBC_HAS_LFS does make the code more complex and
> the benefit to disable it to save some bytes is not high enough.
> 
> Most users have UCLIBC_HAS_LFS enabled and it is enabled by default.
> 
> Attached is a patch.
> 
> Any comments?

Looks good to me, thought maybe Vineet has another opinion on that.

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


Re: [uclibc-ng-devel] [RFC PATCH v4 1/1] libpthread: Fix inclusion of unwind code.

2016-11-30 Thread Ignacy Gawędzki
On Wed, Nov 30, 2016 at 06:40:01AM +0100, thus spake Waldemar Brodkorb:
> Hi Ignacy,

Hi Waldemar,

> Ignacy Gawędzki wrote,
> 
> > Since librt and libpthread are now integrated into libc, including
> > unwind-resume and unwind-forcedunwind implementations of unwind code
> > makes no sense.  Only unwind-forcedunwind is now included with
> > functions hidden to avoid them overriding the ones from libgcc_s.
> 
> I tested the patch and I think I will push it in the next days.

Nice.

> Sorry that it took a while, but the removal of the test suite
> took a while. Now the test suite is compiled as a normal software
> package and not with the initial gcc.

That's definitely the right way to go.

> Therefore no regressions seen with your patch.

I'm happy to hear that. =)

> Any other news to the patch?

No.  We've been using it on uClibc-ng 1.0.18 in-house for weeks
without any noticeable problem.

Regards,

Ignacy

-- 
Ignacy Gawędzki
R Engineer
Green Communications
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel