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