Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 28 Feb 1999 23:18:34 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        jdp@polstra.com (John Polstra)
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Fixing dlopen, ld.so, and upgrading the resolver
Message-ID:  <199902282318.QAA21965@usr07.primenet.com>
In-Reply-To: <199902270543.VAA05852@vashon.polstra.com> from "John Polstra" at Feb 26, 99 09:43:36 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > SVR4 handles this with a libdlopen, and the execution class loader
> > premaps the ld.so into all images.  The library stub is basically
> > jump table data for the premapped ld.so.
> 
> Terry keeps claiming that operating system X supports dlopen in static
> programs, and I keep saying he's wrong.  Rather than go through it
> again, I'll just suggest that interested readers go to this URL:
> 
> http://www.freebsd.org/cgi/search.cgi?words=dlopen+AND+static+AND+jdp&max=50&sort=date&source=freebsd-stable&source=freebsd-current&source=freebsd-hackers
> 
> As you'll see, Terry has spewed this particular bit of misinformation
> over and over since January, 1996.  It's just as wrong today as it
> was then.

Solaris provides this functionality by causing the resulting binary
to be linked shared against libdl.so, and static against all others.


solaris%1 man libdl
File Formats                                             libdl(4)

NAME
     libdl - the dynamic linking interface library

SYNOPSIS
     cc [ flag ... ] file ...  -ldl [ library ... ]

DESCRIPTION
     Functions in this  library  provide  direct  access  to  the
     dynamic  linking facilities.  This library is implemented as
     a filter on the runtime linker (see ld.so.1(1)).


SVR4, which is *not* Solaris, despite continual pointing at Solaris
every time I broach this subject, can provide dlopen functionality by:

1)	Using libelf to open the image to locate sections in ld.so

2)	mapping ld.so sections

3)	using the symbol section to locate ld.so entry points

4)	providing stub functions to access ld.so function directly

In the developement version of UnixWare 2.x that I used while at
Novell/USG (the former USL), based on SVR4.2 ES/MP, this functionality
was packaged into something called "libdlopen".  I believe the author
was Kurt Mahon, a kernel engineer at the Novell, Sandy site, and
whose office was almost directly one floor below mine.


Regardless, whether or not SVR4 can support this is irrelevent as
to whether or not FreeBSD *should* support this.

That FreeBSD *should* support dlopen in static binaries (with the
addition of a library, of course) is the important point.

We need to quit rat-holing on whether or not SVR4 supports it; I
worked on an SVR4 that did, but the point is irrlevant.  That the
SVR4's that you are used to don't support this is not sufficient
justification for FreeBSD to *not* support it.


If I were to provide a libdlopen.a for use in static binaries, and
which would fail in the absence of ld.so, would the code be committed?

Alternately, if I were to provide a modified crt0.o for static
linking that did the same thing as the one for dynamic linking, but
did not fail if the .init section was empty in the absence of an
ld.so (e.g., use the same code for static and dynamic), would *that*
be committed?


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902282318.QAA21965>