From: Joshua Lock <josh@openedhand.com>
To: poky@yoctoproject.org
Subject: Re: elfutils build fails on Fedroa 14
Date: Wed, 15 Dec 2010 16:44:55 +0000 [thread overview]
Message-ID: <1292431496.18631.2.camel@scimitar> (raw)
In-Reply-To: <9DA5872FEF993D41B7173F58FCF6BE9404FAD617@orsmsx504.amr.corp.intel.com>
On Wed, 2010-12-15 at 08:26 -0800, Kamble, Nitin A wrote:
> >
> > On (05/12/10 13:57), Wolfgang Denk wrote:
> > > Trying to build on a Fedora 14 box, elfutis fails with this error:
> > >
> > > ...
> > > | make[2]: Entering directory `/opt/poky/build-laverne-4.0-
> > kilauea/tmp/work/x86_64-linux/elfutils-native-0.148-r1/elfutils-
> > 0.148/src'
> > > ...
> > > | ccache gcc -std=gnu99 -Wall -Wshadow -Werror -Wunused -Wextra -
> > fgnu89-inline -Wformat=2 -isystem/opt/poky/build-laverne-4.0-
> > kilauea/tmp/sysroots/x86_64-linux/usr/include -O2 -Wl,-rpath-
> > link,../libelf:../libdw -L/opt/poky/build-laverne-4.0-
> > kilauea/tmp/sysroots/x86_64-linux/usr/lib -Wl,-rpath-
> > link,/opt/poky/build-laverne-4.0-kilauea/tmp/sysroots/x86_64-
> > linux/usr/lib -Wl,-rpath,/opt/poky/build-laverne-4.0-
> > kilauea/tmp/sysroots/x86_64-linux/usr/lib -Wl,-O1 -o objdump objdump.o
> > ../libasm/libasm.so ../libebl/libebl.a ../libelf/libelf.so
> > ../lib/libeu.a -ldl
> > > | ./ld: unrecognized option '--no-add-needed'
> > > | Try `ld --help' or `ld --usage' for more information.
> > > | collect2: ld returned 64 exit status
> > > | make[2]: *** [addr2line] Error 1
> > > | make[2]: *** Waiting for unfinished jobs....
> > > | ./ld: unrecognized option '--no-add-needed'
> > > | Try `ld --help' or `ld --usage' for more information.
> > > | collect2: ld returned 64 exit status
> > > | make[2]: *** [elfcmp] Error 1
> > > | ./ld: unrecognized option '--no-add-needed'
> > > | Try `ld --help' or `ld --usage' for more information.
> > > | collect2: ld returned 64 exit status
> > >
> > > In Fedora 14, the following command gets generated:
> > >
> > > /usr/libexec/gcc/x86_64-redhat-linux/4.5.1/collect2 --build-id --no-
> > add-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-
> > linker /lib64/ld-linux-x86-64.so.2 -o objdump /usr/lib/gcc/x86_64-
> > redhat-linux/4.5.1/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-
> > linux/4.5.1/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-
> > linux/4.5.1/crtbegin.o -L/opt/poky/build-laverne-4.0-
> > kilauea/tmp/sysroots/x86_64-linux/usr/lib -L/usr/lib/gcc/x86_64-redhat-
> > linux/4.5.1 -L/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib64
> > -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-
> > linux/4.5.1/../../.. --add-needed -rpath-link ../libelf:../libdw -
> > rpath-link /opt/poky/build-laverne-4.0-kilauea/tmp/sysroots/x86_64-
> > linux/usr/lib -rpath /opt/poky/build-laverne-4.0-
> > kilauea/tmp/sysroots/x86_64-linux/usr/lib -O1 objdump.o
> > ../libasm/libasm.so ../libebl/libebl.a ../libelf/libelf.so
> > ../lib/libeu.a -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
> > --as-needed -lgcc_s --no-
> > as
> > > -needed /usr/lib/gcc/x86_64-redhat-linux/4.5.1/crtend.o
> > /usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib64/crtn.o
> > > ./ld: unrecognized option '--no-add-needed'
> > > Try `ld --help' or `ld --usage' for more information.
> > > collect2: ld returned 64 exit status
> > >
> > > Unfortunately the "ld" command in elfutils-0.148 does not understand
> > > the '--no-add-needed'; I've tried to find any existing fixes for
> > > this, but what I found just added a "-Xlinker --add-needed" to the
> > > command line, which does not help here since ./ld understands neither
> > > '--no-add-needed' nor '--add-needed'.
> > >
> > > Any ideas?
> >
> > I think we really dont need the tools part only libelf is needed so one
> > way
> > is to not build everything but just do targetted make targets and avoid
> > building tools as its happening
> >
> > secondly you could try to add --program-prefix="elfutils-" or somesuch
> > then the linker from elfutils will be called elfutils-ld but I dont
> > know if
> > it will work because renaming happens during the install phase you have
> > to try it out.
> >
> > -Khem
>
> Has anybody else seeing this failure? I am building on the fedora 14
> x86_64, with latest master and I do not see this issue.
>
> Wolfgang, Are you using any different layer or machine with this failure ?
I suspect this is an issue whereby an unsupported MACHINE has been added
and something has caused the linker to become subtly broken. This may
well be a BSP documentation issue - I'm expecting that this may all stem
from some missing COMPATIBLE_MACHINE declaration resulting in an
unsupported mixture of components being used.
I'm hoping to get time to step through this issue and reproduce. Unless
someone else would like to volunteer? ;-)
Cheers,
Joshua
--
Joshua Lock
Intel Open Source Technology Centre
next prev parent reply other threads:[~2010-12-15 16:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-05 12:57 elfutils build fails on Fedroa 14 Wolfgang Denk
2010-12-11 10:47 ` Khem Raj
2010-12-15 16:26 ` Kamble, Nitin A
2010-12-15 16:44 ` Joshua Lock [this message]
2010-12-15 16:49 ` Joshua Lock
2010-12-17 1:19 ` Kamble, Nitin A
2010-12-17 3:31 ` Khem Raj
2010-12-21 14:07 ` Richard Purdie
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=1292431496.18631.2.camel@scimitar \
--to=josh@openedhand.com \
--cc=poky@yoctoproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.