This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: RFH: libgcc_s.so being unnecessarily linked for mipsel-linux crosscompiler...
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: David Daney <ddaney at avtrex dot com>
- Cc: Daniel Jacobowitz <drow at false dot org>, gcc at gcc dot gnu dot org,binutils at sources dot redhat dot com
- Date: Fri, 29 Jul 2005 15:23:22 +0930
- Subject: Re: RFH: libgcc_s.so being unnecessarily linked for mipsel-linux crosscompiler...
- References: <60776.64.85.15.162.1122599245.squirrel@webmail4.pair.com> <42E996FD.1000208@avtrex.com> <20050729032029.GA12838@nevyn.them.org> <42E9A42B.50304@avtrex.com>
On Thu, Jul 28, 2005 at 08:36:11PM -0700, David Daney wrote:
> I can detect this special case in _bfd_mips_elf_add_symbol_hook() and
> cause it to be ignored, thus solving the problem.
>
> Does this seem like a reasonable course of action?
Yes. That does cost a strcmp on every symbol in every input file
though. It's somewhat better to do strcmp once on every global symbol
in adjust_dynamic_symbol. See elf32-ppc.c handling of _SDA_BASE_.
Even better would be a hash lookup in something run before
adjust_dynamic_symbol, say, always_size_sections. I didn't think of
that when I added the ppc code.
> I am not sure how that dynamic symbol got into the shared objects in the
> first place. I suppose if the proper solution was to not put it there
> in the first place, I could fix that
It would be good if new shared objects don't have this bug. Forcing the
sym local should cure it.
> and rebuild the world. But that
> would be much more work.
>
> David Daney.
--
Alan Modra
IBM OzLabs - Linux Technology Centre