public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: make the shared library optional
Date: Mon, 10 Nov 2014 16:49:18 +0000	[thread overview]
Message-ID: <5460EC8E.2010101@imgtec.com> (raw)
In-Reply-To: 20141108151409.GC28913@blokker.redhat.com

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

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=9406d4dc02b5fa452ff487b1c5ce9a891388b919

>>> 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.

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

             reply	other threads:[~2014-11-10 16:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-10 16:49 Vicente Olivert Riera [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-11-11  9:11 Mark Wielaard
2014-11-08 15:14 Mark Wielaard
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=5460EC8E.2010101@imgtec.com \
    --to=vincent.riera@imgtec.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).