This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
No Subject
- To: axp-list at redhat dot com, egcs-bugs at cygnus dot com
- From: Dan Weeks <danimal at blueskystudios dot com>
- Date: Sat, 10 Jan 1998 15:09:29 -0500
bug-glibc@prep.ai.mit.edu
Bcc: R & D <rnd@blueskystudios.com>,
The Mighty Mighty PSItones <psi@blueskystudios.com>
Subject: dlopen() bug on Linux/Alpha
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid
Comments: Hyperbole mail buttons accepted, v04.023.
I-Am: danimal
Precedence: special-delivery
Return-Receipt-To: danimal@blueskystudios.com
X-Face: $Y&:wju!9uUmZ{k1W-gF%uw'0!`!U#dbXZ&FeSqfjdsKw.[[6ZAqb<p/|4Xp&eS5O(?<]z{
PR="@wd$A:Ebe0o%S_d;mPk?%%Pep:V+Q'S`.I4^^7._<YUg`H(N-<I;{,f/*8PAC=c|?H+k=J"[wf
ZK7c9>>n;&:+7x)Kk)u%)MWoKruZ7(v*y|-_f'i:~c[QgOX!>Z:ChYd)
Hello:
I am using Red Hat 5.0 on a 433 MHz Carrera computer running at
kernel level 2.0.32. Currently I have the latest glibc (2.0.5c build
13) rpm from Red Hat. I have also built a new set of the glibc
libraries using these sources. The only compiler that I have used for
both building the libraries and our code is egcs-1.0.1.
The problem that we are running into is that when we attempt to
open a shared library (*.so) that we have compiled the dlopen() call
fails. These shared libraries are dynamic procedures for a larger
program that we write in-house. During the linking phase for the shared
library we use the options -shared and -ignore_unresolved so that any
symbols that are in the larger program will be passed over and an .so
will be produced (I'm not sure that -ignore_unresolved is supported on
Linux, here is its entry in the SGI man page:
-ignore_unresolved
This option causes an executable or DSO to be produced and ld to
exit with zero status even if there are unresolved symbols;
resolution of these symbols will be completed by rld . If linking
-call_shared, a list of the unresolved symbols will be output (as it
always is for -call_shared). If linking -shared, no such list will
be output. If linking -non_shared, this option is ignored (and
-no_unresolved is used, as it always is for -non_shared). This
option is the default for -shared linking, but not for -call_shared
or -non_shared.
).
I looked at the GNATS system at GNU but the only dlopen reference I
found was at
http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/387 . This
seems to be like the problem we are having, but I can't tell exactly.
I guess that what could be happening is that the shared library is
loaded, can't find symbols in the main program and dies, killing the
main process.
I noticed that a glibc-2.0.6 was available on prep.ai.mit.edu but it
looks to not have a fix for dlopen in it.
If anyone has any insight into this bug i would appreciate some
feedback. Also, if a bug report at GNU is needed I will gladly submit
one.
-danimal
--
Dan Weeks <danimal@blueskystudios.com>
Blue Sky|VIFX http://www.blueskystudios.com/ http://www.vifx.com/
Harrison, New York 914/381.8400 - Los Angeles, California 310/822.8872
"There's no off position on the genius switch!" - D. Letterman