dlopen() bug on Linux/Alpha ( Was: Unidentified subject!)

[Dan Weeks <danimal at blueskystudios dot com>]

Let me make a correction to this.  When the dlopen call is used it
does _not_ kill the executable, it only returns a null file handle.
When we use the exact same code on an SGI the shared library is opened 
and everything works fine.

-danimal

Dan Weeks writes:
 > 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.
 > 
-- 
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
"Good, Bad, I'm the guy with the gun." - Ash