public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: make the shared library optional
Date: Sat, 08 Nov 2014 16:14:09 +0100	[thread overview]
Message-ID: <20141108151409.GC28913@blokker.redhat.com> (raw)
In-Reply-To: 545CE994.10301@imgtec.com

[-- Attachment #1: Type: text/plain, Size: 3041 bytes --]

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

             reply	other threads:[~2014-11-08 15:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-08 15:14 Mark Wielaard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-11-11  9:11 Mark Wielaard
2014-11-10 16:49 Vicente Olivert Riera
2014-11-07 16:27 Vicente Olivert Riera
2014-11-07 15:47 Vicente Olivert Riera
2014-11-07 14:16 Mark Wielaard
2014-11-05 13:32 Vicente Olivert Riera
2014-11-04 17:01 Petr Machata
2014-11-03 14:45 Vicente Olivert Riera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141108151409.GC28913@blokker.redhat.com \
    --to=mjw@redhat.com \
    --cc=elfutils-devel@lists.fedorahosted.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).