This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: libstdc++ libtool lossage
- From: Jakub Jelinek <jakub at redhat dot com>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Sun, 24 Feb 2002 04:54:28 -0500
- Subject: Re: libstdc++ libtool lossage
- References: <rth@redhat.com> <200202240151.UAA22048@makai.watson.ibm.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Sat, Feb 23, 2002 at 08:51:17PM -0500, David Edelsohn wrote:
> It sounds more like GNU/Linux has a loading and relocation
> performance problem which you are trying to work around by omitting as
> many shared library dependencies as you can avoid. That does not sound
> like a good long-term design. Note that this is one area where AIX's
> design is very clean and efficient, if you cared to research the topic.
Show me a system where it doesn't matter.
Over 80% of shared libraries on typical Linux system are plain C shared
libraries. Having every such shared library linked against libgcc_s.so means
every program is linked against it.
I cannot imagine how you can manage to avoid a couple
of non-shareable dirty pages per every single process, a bunch of system calls
and relocation/symbol lookup costs per each process just because of libgcc_s
(which is usually not used at all, worst case some divide routine or
something (but those are usually already exported from glibc)).
Jakub