*BSD News Article 50012


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!noc.netcom.net!netcomsv!uu3news.netcom.com!netcomsv!uucp3.netcom.com!polstra!not-for-mail
From: jdp@polstra.com (John Polstra)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Bug in 2.0.5's dlopen() functionality
Date: 1 Sep 1995 10:42:20 -0700
Organization: Polstra & Co., Seattle, WA
Lines: 50
Message-ID: <427gls$jl5@seattle.polstra.com>
References: <87pwhri1b7.fsf@hrothgar.mindspring.com> <41s307$rfn@reason.cdrom.com> <874tyz6qdm.fsf@interbev.mindspring.com> <425h0b$j2l@reason.cdrom.com>
NNTP-Posting-Host: seattle.polstra.com

In article <425h0b$j2l@reason.cdrom.com>,
Jordan K. Hubbard <jkh@FreeBSD.org> wrote:
> Robert Sanders <rsanders@mindspring.com> wrote:
> >Ick.  Is that intended, or just the current state of affairs?  ELF can
> >handle recursive shared library dependencies, and it's very very nice.
> >It certainly seems that this is something the current shared library
> >system should be able to handle.  And I can swear that the current one
> >at least made some effort to.  I guess it's time to RTFS. :)
> 
> Well, that's just my understanding of it given about a 15 minute attempt
> to make this work myself.  I could be wrong, and a thorough attempt to RTFS
> would indeed be highly advisable!  If it turns out that I am wrong, I
> wouldn't mind a confirmation of this..

I'll confirm it -- you're wrong :-).

I dug into the source of ld.so yesterday afternoon.  Pretty clearly,
the code was intended to handle recursive shared library dependencies.
There's a function dl_cascade() that is supposed to handle them.  But it
looks like the person who worked on that aspect of it couldn't get it
to work right -- as evidenced by this little snippet:

    #if 0
		    /*
		     * XXX - this doesn't work for some reason.  not
		     * at all sure why.  -mrg
		     */     
		    if (dl_cascade(smp2) == 0)
			    return 0;
    #endif

Anyway, I studied it, figured out what was wrong, and fixed it.  A
contrived test case with 4 levels of cascaded shared library
dependencies (including multiple dependencies on some of them) now
works fine.  (It failed with the original ld.so.)

I also added some new code to cascade-UNload the appropriate shared
libraries when dlclose() is called.

I am using this new ld.so on my system, and haven't seen any problems
with it so far.  Robert (the original poster) is also going to try it
out with his Python installation, to make sure that it solves his
particular problem.

Once I am convinced that I haven't broken anything, I'll send the patch
to the FreeBSD team.
-- 
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth