This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

No Subject


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]