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 i
Daniel Jacobowitz wrote:
On Thu, Jul 28, 2005 at 07:39:57PM -0700, David Daney wrote:
It seems that the linker thinks that any shared object that references
the magic _gp_disp symbol actually provides it. Since all mips objects
reference _gp_disp, ld thinks that all shared objects are require
On Thu, Jul 28, 2005 at 07:39:57PM -0700, David Daney wrote:
> It seems that the linker thinks that any shared object that references
> the magic _gp_disp symbol actually provides it. Since all mips objects
> reference _gp_disp, ld thinks that all shared objects are required to
> resolve all th
[EMAIL PROTECTED] wrote:
ddaney wrote:
I have a a mipsel-linux cross compiler (gcc-3.4.3/binutils-2.16.1)
and whenever I compile even the simplest hello-world.c libgcc_s.so is
linked.
Just curious -- how did you build your cross-compiler?
I have a bunch of rpm build scripts, but they pret
ddaney wrote:
> I have a a mipsel-linux cross compiler (gcc-3.4.3/binutils-2.16.1)
> and whenever I compile even the simplest hello-world.c libgcc_s.so is
linked.
Just curious -- how did you build your cross-compiler?
Do toolchains built by crosstool have this problem?
(I'm away from home, or I'd
