- Subject: libc/1326: Bug (or at least undocumented restriction) in DL routines
- From: GregNoel at san dot rr dot com
- Date: Mon Sep 27 17:10:06 1999
Topics:
libc/1326: Bug (or at least undocumented restriction) in DL routines
----------------------------------------------------------------------
Date: Fri, 24 Sep 1999 16:29:40 -0700
From: GregNoel@san.rr.com
To: bugs@gnu.org
Subject: libc/1326: Bug (or at least undocumented restriction) in DL routines
Message-Id: <199909242329.QAA00958@dt0b1ncd.san.rr.com>
>Number: 1326
>Category: libc
>Synopsis: Apparent limit on the number of symbols that can be loaded dynamically
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: libc-gnats
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Sep 24 19:20:01 EDT 1999
>Last-Modified:
>Originator: Greg Noel
>Organization:
retired UNIX guru
>Release: libc-2.1.2
>Environment:
PowerPC running MkLinux pre-R1, gcc 2.95.1
Also happens on LinuxPPC system with similar environment
Host type: powerpc-redhat-linux-gnu
System: Linux dt0b1ncd 2.0.37-osfmach3 (GENERIC #7) ENLEVEL #50 Wed Mar 3 22:00:33 CST 1999 ppc unknown
Architecture: ppc
Addons: crypt linuxthreads
Build CFLAGS: -O2 -fsigned-char
Build CC: gcc
Compiler version: 2.95.1 19990816 (release)
Kernel headers: 2.1.24
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: no
Build profile: yes
Build omitfp: no
Build bounded: no
Build static-nss: no
Stdio: libio
>Description:
RoadRunner mangles outgoing mail addresses; no matter what the return
address says, please reply to GregNoel@san.rr.com.
Attempts to run Mozilla (www.mozilla.org) on a PowerPC architecure fail,
apparently because there is a hard limit on the number of symbols that
can be loaded from dynamic libraries. Mozilla has well over 100 dynamic
libraries just to boot the system, and more are being added every day to
support plugins and the like, so there are many thousands of symbols that
have to be loaded.
>How-To-Repeat:
Get the Mozilla sources. Compile them. Try running the resulting binary.
Note that it segfaults while trying to load a dynamic library, often by
branching to an invalid memory location.
If you're ambitious, vary the compile options, and note that the segfault
occurs when trying to load a different library---chose options for fewer
symbols and it gets further.
An RPM of the milestone 9 snapshot is available from linuxppc.org if you
want to test it quickly; it's compiled with no debugging symbols and
maximum optimumization; it gets further than other combinations.
If you don't want to create the full build environment, contact me and
I'll build any combination of options you want.
>Fix:
Damifino. That's why I'm contacting you. We need a fix, quickly; this
is a stopper for us. If we can't solve it, it will mean that PPC-based
Linux systems probably won't be supported by Netscape 5.0.
I've spent several days groveling in the PPC-specific code for dlopen()
and friends. I'm new to PPC assembly, so it's very slow going. If the
author(s) of the PPC-specific code could contact me, if only to confirm
that I'm correct in my analysis, I'd appreciate it.
>Audit-Trail:
>Unformatted:
------------------------------
End of forward5KAggS Digest
***************************