This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why long command line for libgcj.so?
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: "H . J . Lu" <hjl at lucon dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: 05 Jun 2002 16:20:50 -0300
- Subject: Re: Why long command line for libgcj.so?
- Organization: GCC Team, Red Hat
- References: <20020604135554.A21927@lucon.org>
On Jun 4, 2002, "H . J . Lu" <hjl@lucon.org> wrote:
> I suspect stack/heap/memory limit. My machine has 1GB RAM. The problem
> is it is almost impossible to run ld in gdb since the command line
> for building libgcj.so is way too long. May I ask why we can't use
> "ld -r" or "ar"/--whole-archive to build libgcj.so? Is that because
> libtool doesn't support it?
On the contrary: it does it this way because it's more efficient.
If we were to use ld -r or ar, we'd either have to have multiple
linking steps (and possibly run into per-object GOT size limits, in
the ld -r case) or have to create an archive out of PIC objects. If
there are no command line length limits that requires us to take one
of these approaches, we just go with everything in a single link
command.
You can force libtool to do multi-step `ld -r' linking by setting the
cache variable that contains the maximum command-line length to a
smaller number.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer