Re: Doing a release?
Il 18 settembre 2013 06:49:44 Thomas Petazzoni ha scritto: Dear uClibc developers, Hi Thomas The last release of uClibc, 0.9.33.2, has been made well over a year ago. However, there is fairly big number of improvements/fixes in the master branch that would be interesting to have in a release. At the Buildroot level, we now have 53 patches in your patch stack against uClibc 0.9.33.2, all coming from the master branch if I'm correct (see http://git.buildroot.net/buildroot/tree/package/uclibc/0.9.33.2). At a first look it seems you have there some patches not part of any uclibc branches ... Likely it would be nice to include them as well. For sure it's time for a 0.9.33.3 but I do also think that we can start a 0.9.34 release from master. Bernard what do you think ? It'd be really nice if uClibc adopted a slightly more frequent release schedule, to more easily allow downstream users to benefit from improvements/fixes. I agree. I know to have been less active recently as my major tasks are currently on the kernel side and SOC bring up but I'll try to respin my contribution to uclibc and upstream several patches we have in STMicro branch. Thanks a lot! Thomas Cheers Carmelo -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Doing a release?
Dear uClibc developers, The last release of uClibc, 0.9.33.2, has been made well over a year ago. However, there is fairly big number of improvements/fixes in the master branch that would be interesting to have in a release. At the Buildroot level, we now have 53 patches in your patch stack against uClibc 0.9.33.2, all coming from the master branch if I'm correct (see http://git.buildroot.net/buildroot/tree/package/uclibc/0.9.33.2). It'd be really nice if uClibc adopted a slightly more frequent release schedule, to more easily allow downstream users to benefit from improvements/fixes. Thanks a lot! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 2/3] buildsys: fix handling of CFLAGS-OMIT from global CFLAGS
Hi Florian Il 17 settembre 2013 17:57:00 Florian Fainelli ha scritto: Hello, 2013/9/13 Filippo ARCIDIACONO : > Currently the Makefile rules are not removing from the global CFLAGS > any of the OMIT cflags declared at file level. This patch fixes it. Do we really need to have two different ways of achieving the same thing? It seems to me that doing: CFLAGS_foo.c += -fno-bar is equivalent to: CFLAGS-OMIT_foo.c += -fbar Is this always true ? I prefer the first one because we do not need to introduce another infrastructure than the one already existing. CFLAGS-OMIT is a construct already used in several other places in uclibc but only applicable at directory level. This patch just extend it to file. > > Signed-off-by: Carmelo Amoroso > Signed-off-by: Filippo Arcidiacono > --- > Makerules |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/Makerules b/Makerules > index 367daa5..54344c5 100644 > --- a/Makerules > +++ b/Makerules > @@ -230,7 +230,8 @@ collect_multi_flags = $(CFLAGS-$(notdir $(patsubst %/,%,$(dir $(d) > > CFLAGS_gen.dep = -MT $@ -MD -MP -MF $(dir $@).$(notdir $@).dep > > -cmd_compile.c = $(CC) -c $< -o $@ $(CFLAGS) \ > +cmd_compile.c = $(CC) -c $< -o $@ \ > + $(filter-out $(CFLAGS-OMIT-$(notdir $<)),$(CFLAGS)) \ > $(CFLAGS-$(suffix $@)) \ > $(filter-out $(CFLAGS-OMIT-$(notdir $<)),$(CFLAGS-$(notdir $( $(CFLAGS-$(subst $(top_srcdir),,$(dir $<))) \ > -- > 1.7.7.6 > > ___ > uClibc mailing list > uClibc@uclibc.org > http://lists.busybox.net/mailman/listinfo/uclibc -- Florian Carmelo _ __ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 3/3] ldso: exclude -fasynchronous-unwind-tables from ldso CFLAGS
On Tue, 17 Sep 2013, Rich Felker wrote:
> On Fri, Sep 13, 2013 at 10:31:53AM +0200, Filippo ARCIDIACONO wrote:
> > At least on ARM, building the ld.so with -fasynchronous-unwind-tables
> > for backtrace is creating a dependencies against libc through libgcc_eh.
> > So it needs to exclude this from the ldso cflags.
>
> Have you figured out why this is happening? I think it's a GCC bug
> which should be reported; we've had similar problems with bogus
> libgcc_eh dependencies on ARM in musl, but fortunately they're much
> easier for us to solve.
If the unwind info requires one of the standard __aeabi_unwind_cpp_pr*
personality routines, the assembler generates an undefined symbol
(R_ARM_NONE relocation) to ensure that personality routine is linked in,
as required by EHABI (ARM IHI 0038A) ("Object producers must emit an
R_ARM_NONE relocation from an exception-handling table section to the
required personality routine to indicate the dependency to the linker.").
As I explained in
, for glibc
it's in fact always OK to have stub rather than real versions of these
personality routines in libc.so.
--
Joseph S. Myers
jos...@codesourcery.com
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 2/3] buildsys: fix handling of CFLAGS-OMIT from global CFLAGS
Hello, 2013/9/13 Filippo ARCIDIACONO : > Currently the Makefile rules are not removing from the global CFLAGS > any of the OMIT cflags declared at file level. This patch fixes it. Do we really need to have two different ways of achieving the same thing? It seems to me that doing: CFLAGS_foo.c += -fno-bar is equivalent to: CFLAGS-OMIT_foo.c += -fbar I prefer the first one because we do not need to introduce another infrastructure than the one already existing. > > Signed-off-by: Carmelo Amoroso > Signed-off-by: Filippo Arcidiacono > --- > Makerules |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/Makerules b/Makerules > index 367daa5..54344c5 100644 > --- a/Makerules > +++ b/Makerules > @@ -230,7 +230,8 @@ collect_multi_flags = $(CFLAGS-$(notdir $(patsubst > %/,%,$(dir $(d) > > CFLAGS_gen.dep = -MT $@ -MD -MP -MF $(dir $@).$(notdir $@).dep > > -cmd_compile.c = $(CC) -c $< -o $@ $(CFLAGS) \ > +cmd_compile.c = $(CC) -c $< -o $@ \ > + $(filter-out $(CFLAGS-OMIT-$(notdir $<)),$(CFLAGS)) \ > $(CFLAGS-$(suffix $@)) \ > $(filter-out $(CFLAGS-OMIT-$(notdir $<)),$(CFLAGS-$(notdir $( $(CFLAGS-$(subst $(top_srcdir),,$(dir $<))) \ > -- > 1.7.7.6 > > ___ > uClibc mailing list > uClibc@uclibc.org > http://lists.busybox.net/mailman/listinfo/uclibc -- Florian ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 3/3] ldso: exclude -fasynchronous-unwind-tables from ldso CFLAGS
On Fri, Sep 13, 2013 at 10:31:53AM +0200, Filippo ARCIDIACONO wrote: > At least on ARM, building the ld.so with -fasynchronous-unwind-tables > for backtrace is creating a dependencies against libc through libgcc_eh. > So it needs to exclude this from the ldso cflags. Have you figured out why this is happening? I think it's a GCC bug which should be reported; we've had similar problems with bogus libgcc_eh dependencies on ARM in musl, but fortunately they're much easier for us to solve. > Signed-off-by: Carmelo Amoroso > Signed-off-by: Filippo Arcidiacono > --- > ldso/ldso/Makefile.in |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/ldso/ldso/Makefile.in b/ldso/ldso/Makefile.in > index 91165c6..65f9a46 100644 > --- a/ldso/ldso/Makefile.in > +++ b/ldso/ldso/Makefile.in > @@ -30,6 +30,8 @@ CFLAGS-ldso/ldso/$(TARGET_ARCH)/ := $(CFLAGS-ldso) > > CFLAGS-ldso.c := -DLDSO_ELFINTERP=\"$(TARGET_ARCH)/elfinterp.c\" > $(CFLAGS-ldso) > > +CFLAGS-OMIT-ldso.c = -fasynchronous-unwind-tables > + How does this work? -fasynchronous-unwind-tables is the GCC default. You need -fno-asynchronous-unwind-tables to turn them off. Rich ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
