From: Paul Mundt <lethal@linux-sh.org>
To: linux-sh@vger.kernel.org
Subject: Re: [uClinux-dev] Re: objdump on libgcc, again
Date: Fri, 02 Apr 2010 07:41:39 +0000 [thread overview]
Message-ID: <20100402074139.GB14056@linux-sh.org> (raw)
In-Reply-To: <201004011442.42027.fabio.giovagnini@aurion-tech.com>
On Thu, Apr 01, 2010 at 02:42:41PM +0200, Fabio Giovagnini wrote:
> in sh-2.6/arch/sh/boot/compressed/Makefile
> there is
> LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
>
> Why this makefile sets LBGCC if it is not required?
>
Because in to the context of this Makefile it is required.
> In data gioved?? 01 aprile 2010 14:39:05, Fabio Giovagnini ha scritto:
> : > OK. I understand, but why there is:
> > sh-uclinux-ld -EB --oformat elf32-shbig-linux -Ttext 0x0c800000 -e
> > startup -T arch/sh/boot/compressed/../../kernel/vmlinux.lds
> > arch/sh/boot/compressed/head_32.o arch/sh/boot/compressed/misc.o
> > arch/sh/boot/compressed/cache.o arch/sh/boot/compressed/piggy.o
> > /home/fgiovagnini/sh7203/sh7203-
> > uclinux-4.4-143/build/target/bin/../lib/gcc/sh-uclinux/4.4.1/libgcc.a -o
> > arch/sh/boot/compressed/vmlinux
> >
> >
> > This is the problem.
> >
The parts you conveniently left out were:
sh-uclinux-ld: /opt/tc/renesas-4.4/bin/../lib/gcc/sh-uclinux/4.4.1/libgcc.a(_ashiftlt.o): attempt to mix FDPIC and non-FDPIC objects
sh-uclinux-ld: failed to merge target specific data of file /opt/tc/renesas-4.4/bin/../lib/gcc/sh-uclinux/4.4.1/libgcc.a(_ashiftlt.o)
sh-uclinux-ld: /opt/tc/renesas-4.4/bin/../lib/gcc/sh-uclinux/4.4.1/libgcc.a(_lshiftrt.o): attempt to mix FDPIC and non-FDPIC objects
sh-uclinux-ld: failed to merge target specific data of file /opt/tc/renesas-4.4/bin/../lib/gcc/sh-uclinux/4.4.1/libgcc.a(_lshiftrt.o)
We build the kernel with -mno-fdpic which means that we won't be able to use
the FDPIC libgcc for the zImage loader. Mangling the BFD target isn't going to
help you here either, although of course if there's another BFD that we should
be using while preserving -mno-fdpic semantics for the kernel build then we can
trivially drop that in, too.
It's certainly worth trying to wean the compressed image off of libgcc, but
we're not quite at that point yet.
prev parent reply other threads:[~2010-04-02 7:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-01 12:42 [uClinux-dev] Re: objdump on libgcc, again Fabio Giovagnini
2010-04-02 7:41 ` Paul Mundt [this message]
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=20100402074139.GB14056@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=linux-sh@vger.kernel.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 NNTP newsgroup(s).