public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: roneng@ca.ibm.com
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] Tool chain ld program -Previous message
Date: Mon, 10 Apr 2000 15:26:28 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590678205012@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590678205003@msgid-missing>



The exact error I am getting is the following
usr/lib/gcc-lib/ia64-cygnus-linux/2.9-ia64-000216/crtbeginS.o(.fini_0x2):
relocation truncated to fit:  PCREL21B fini
collect2:  ld returned 1 exit status

Changing the max page size seems to solve this problem. But the error
message seems to indicate
that this might be a problem with the maximum size of shared library ld can
create. Other then changing the
max page size Is there a command line parameter of code change to ld that
will allow larger static library sizes?

Thanks,
Ronen Grosman
- e-mail roneng@ca.ibm.com



Jim Wilson <wilson@cygnus.com> on 04/06/2000 03:50:22 PM

Please respond to Jim Wilson <wilson@cygnus.com>

To:   Ronen Grosman/Toronto/IBM@IBMCA
cc:   linux-ia64@linuxia64.org
Subject:  Re: [Linux-ia64] Tool chain ld program -Previous message
      incomplete




     The link seems to be failing with Reallocation error.

That isn't enough info to be useful.  Also, I suspect that you got a
"reloc"
error not "Realloc" error.

     The changed.Cygnus file shows that this parameter was changed on
1999-11-06
     by cygnus from 0x10000000 to 0x10000,
     which was the original value was wondering if anyone knew why this
changed
     occurred, and if undoing the change is I did will
     cause any problems?

I don't recall exactly what it was.  I believe it had something to do with
how
physical and virtual addresses in an executable got allocated.  With the
smaller page size, I think we either got smaller executables (less padding)
or smaller load images (less wasted virtual address space).  Or maybe it
was
done because the resulting executables could be loaded more efficiently.
It
should be visible if you look at the resulting executable.

In any case, we aren't going to change it back unless we get some
explanation
of why the original value is better than the current value, so I need a
better explanation of what is going on, or a better bug report.

Jim






  parent reply	other threads:[~2000-04-10 15:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-06 13:25 [Linux-ia64] Tool chain ld program -Previous message incomplete roneng
2000-04-06 19:50 ` Jim Wilson
2000-04-10 15:26 ` roneng [this message]
2000-04-10 19:10 ` Jim Wilson

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=marc-linux-ia64-105590678205012@msgid-missing \
    --to=roneng@ca.ibm.com \
    --cc=linux-ia64@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