problem in building ncurses with uclibc
hi, gcc 4.3.3 ncurses 5.7 I am trying to build(cross compiling for mips) ncurses using a uclibc toolchain but it gives following error; lib64\libc.a(nsswitch.o): (.data.rel+0x18):undefined reference to '_nss_files_endaliasent' uclibc does not support nss (it is supported by glibc), how should i solve this? my config command is given below; ./configure --prefix=/ncurses_crosscompiled --disable-static --enable-shared --target=mips64--linux-gnu CC=$_ROOT/tools/bin/mips64--linux-gnu-gcc-4.3.3 LDFLAGS=-L$_ROOT/tools/lib/gcc/mips64--linux-gnu/4.3.3/ plus ncurses mailing list says that ncurses has nothing to do with this symbol _nss_files_endaliasent or library. Kindly guide. -Name of the embeded device concealed ___ 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 carmelo.amor...@st.com Signed-off-by: Filippo Arcidiacono filippo.arcidiac...@st.com --- 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
Re: [PATCH 2/3] buildsys: fix handling of CFLAGS-OMIT from global CFLAGS
Hello, 2013/9/13 Filippo ARCIDIACONO filippo.arcidiac...@st.com: 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 carmelo.amor...@st.com Signed-off-by: Filippo Arcidiacono filippo.arcidiac...@st.com --- 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 $(D \ $(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 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 https://sourceware.org/ml/libc-alpha/2012-05/msg00705.html, 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
Hi Florian Il 17 settembre 2013 17:57:00 Florian Fainelli f.faine...@gmail.com ha scritto: Hello, 2013/9/13 Filippo ARCIDIACONO filippo.arcidiac...@st.com: 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 carmelo.amor...@st.com Signed-off-by: Filippo Arcidiacono filippo.arcidiac...@st.com --- 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 $(D \ $(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
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: Doing a release?
Il 18 settembre 2013 06:49:44 Thomas Petazzoni thomas.petazz...@free-electrons.com 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
