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.
> 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='"/usr/share/locale"' -I. -I.. -I. -I. -I../lib -I..
-I./../libelf -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -std=gnu99 -Wall
-Wshadow -Werror -Wunused -Wextra -fgnu89-inline -Wformat=2 -fpic
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -pipe -Os -g2 -static -c -o
color.o color.c
color.c: In function ‘parse_opt’:
color.c:135:5: error: passing argument 4 of ‘argp_help’ discards ‘const’
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-buildroot-linux-uclibc/sysroot/usr/include/argp.h:469:13:
note: expected ‘char *’ but argument is of type ‘const char *’
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.
> 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.
Thanks,
Mark