From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3604140938193097296==" MIME-Version: 1.0 From: Vicente Olivert Riera To: elfutils-devel@lists.fedorahosted.org Subject: Re: make the shared library optional Date: Mon, 10 Nov 2014 16:49:18 +0000 Message-ID: <5460EC8E.2010101@imgtec.com> In-Reply-To: 20141108151409.GC28913@blokker.redhat.com --===============3604140938193097296== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 11/08/2014 03:14 PM, Mark Wielaard wrote: > On Fri, Nov 07, 2014 at 03:47:32PM +0000, Vicente Olivert Riera wrote: >>> It looks like the issue is with the crtbeginT.o code, not with any of >>> the elfutils objects? I don't immediately know why that particular >>> object is linked into the shared library. Does the toolchain pick up the >>> correct version? >> >> I'm sorry, the correct version of what? Also, that's an external >> toolchain and I don't have much information about it :S > = > I guess the issue is just that the setup tries to do a static build, > but doesn't patch the elfutils build enough, so some parts still don't > get build staticly and when linking against the static crtbeginT.o > things fail. As Petr explained building elfutils fully static is not > really supported and might need some ugly hacks. That's fine, we already disabled elfutils for static builds in Buildroot: http://git.buildroot.net/buildroot/commit/?id=3D9406d4dc02b5fa452ff487b1c5c= e9a891388b919 >>> It looks like that is a fairly old 0.155 build with several patches >>> applied. Have you tried latest elfutils 0.160 or current git? >> >> I have tried elfutils-0.160, but I'm having this error: >> >> /br/output/host/usr/bin/mipsel-linux-gcc -D_GNU_SOURCE -DHAVE_CONFIG_H >> -DLOCALEDIR=3D'"/usr/share/locale"' -I. -I.. -I. -I. -I../lib -I.. >> -I./../libelf -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -std=3Dgnu99 -Wa= ll >> -Wshadow -Werror -Wunused -Wextra -fgnu89-inline -Wformat=3D2 -fpic >> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -pipe -Os -g2 -static -c -o >> color.o color.c >> color.c: In function =E2=80=98parse_opt=E2=80=99: >> color.c:135:5: error: passing argument 4 of =E2=80=98argp_help=E2=80=99 = discards =E2=80=98const=E2=80=99 >> qualifier from pointer target type [-Werror] >> program_invocation_short_name); >> ^ >> In file included from color.c:34:0: >> /home/ldap/vriera/work/mips-buildroots/mips32/output/host/usr/mipsel-bui= ldroot-linux-uclibc/sysroot/usr/include/argp.h:469:13: >> note: expected =E2=80=98char *=E2=80=99 but argument is of type =E2=80= =98const char *=E2=80=99 >> extern void argp_help (__const struct argp *__restrict __argp, >> ^ >> cc1: all warnings being treated as errors >> make[3]: *** [color.o] Error 1 > = > That is strange. argp_help does indeed take a non-const char *. > But program_invocation_short_name is defined as non-const char * too > in errno.h. You might be using a non-GNU glibc? Some libcs are slightly > broken. It's uClibc. >>> If you think any of those patches are useful could you submit them so we >>> can review them for inclusion upstream? >> >> Please have a look to those patches here. I think some of them can be >> useful: >> >> http://git.buildroot.net/buildroot/tree/package/elfutils > = > Those seem hacks to work around bugs/missing features in uClibc. > Normally elfutils relies on glibc features whenever possible. > I am not against supporting other libc implementations, but it shouldn't > create ugly hacks. The memcpy one is a workaround for something odd in our > code. I'll propose a simpler cleanup for that. But for the others we > really need someone that understands the patches to propose and explain > them on the list so we can discuss and see whether or not they make sense > to apply to mainline. I'm sure that if you contact with the guy who signed-of-by those patches (Thomas Petazzoni) he will be happy to help :-) Best regards, -- = Vicente Olivert Riera Graduate Software Engineer, MIPS Processor IP Imagination Technologies Limited t: +44 (0)113 2429814 www.imgtec.com --===============3604140938193097296==--