From: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: make the shared library optional
Date: Fri, 07 Nov 2014 16:27:41 +0000 [thread overview]
Message-ID: <545CF2FD.5030805@imgtec.com> (raw)
In-Reply-To: 545CE994.10301@imgtec.com
[-- Attachment #1: Type: text/plain, Size: 4346 bytes --]
Dear Mark Wielaard,
On 11/07/2014 03:47 PM, Vicente Olivert Riera wrote:
> Dear Mark Wielaard,
>
> On 11/07/2014 02:16 PM, Mark Wielaard wrote:
>> On Mon, 2014-11-03 at 14:45 +0000, Vicente Olivert Riera wrote:
>>> I'm having a failure when doing a static build of elfutils because it
>>> tries to build a shared library (.so). Could it be possible to add a
>>> configure option to disable the shared library so only the static one
>>> (.a) would be built?
>>>
>>> This is the failure I'm talking about:
>>>
>>> /home/chroot/media/code/buildroot/autobuilder/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/4.8.3/../../../../mipsel-buildroot-linux-uclibc/bin/ld:
>>> /home/chroot/media/code/buildroot/autobuilder/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/4.8.3/crtbeginT.o:
>>> relocation R_MIPS_HI16 against `a local symbol' can not be used when
>>> making a shared object; recompile with -fPIC
>>> /home/chroot/media/code/buildroot/autobuilder/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/4.8.3/crtbeginT.o:
>>> could not read symbols: Bad value
>>> collect2: error: ld returned 1 exit status
>>> Makefile:939: recipe for target 'libelf.so' failed
>>> make[3]: *** [libelf.so] Error 1
>
>
> thanks a lot for your reply.
>
>
>> Does that failure also happen with a normal (not patched) build?
>
> Those patches are necessary. Otherwise it will fail at many points. You
> can see the comments on the patches:
>
> http://git.buildroot.net/buildroot/tree/package/elfutils
>
>> 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
>
>>> The full build log is here:
>>>
>>> http://autobuild.buildroot.net/results/16f/16f6956d5a215fe678a45cc4b24ba196309ee05c/build-end.log
>>
>> 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
After removing all -Werror options (passing --disable-werror to the
configure script doesn't work or is not enough) I got rid of that error
and now I see the static problem again (version 0.160):
mipsel-buildroot-linux-uclibc/4.8.3/crtbeginT.o: relocation R_MIPS_HI16
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC
/br/output/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/4.8.3/crtbeginT.o:
could not read symbols: Bad value
>> 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
>
> Best regards,
>
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-07 16:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-07 16:27 Vicente Olivert Riera [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-08 15:14 Mark Wielaard
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=545CF2FD.5030805@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).