Re: HEADS UP: new NSS

John Polstra wrote:
> In article <20030418014500.B94094_at_iclub.nsu.ru>,
> Max Khon  <fjoe_at_iclub.nsu.ru> wrote:
> > we need either allow dlopen(3) to be used in statically linked programs
> > or move to dynamically linked /.
> 
> Moving to a fully dynamically linked system sounds easier to me.
> But in the past there has been strong opposition to the idea every
> time it has been proposed.

FWIW, I have some static "libdlopen" patches, but you have to
modify the internal compiler glue to use them.  The problem is
that you can't have multiple init sections, only multiple inits,
and that that only really works with C++, if you want to put
them in your code.

The main modification is to stuff the dlopen stuff into the
__CTOR_LIST__, and then make __ctors() pass an argument to the
constructor.  That's because __do_dynamic_link() needs an
argument (it calls it "argv", but it's really "all the data
you need to fill out "crt_ldso").

If you look in /usr/src/lib/csu/i386/crt0.c, and in the code
in /usr/src/lib/csu/i386/c++rt0.c, you'll see what I mean.

The actual modifications aren't hard; but you will have to
give up resolving symbols in your own binary, as the price
(i.e. the .init on the .so you load will have to call a
"well known callback"; this is pretty easy: add a parameter
to the passing of the dlopen() call into the .so you are
loading of a function to call to register to get symbols;
or you could just use statically linked PIC binaries with
symbols attached, and open them as .so's, even though they
are not named that way).

-- Terry