Re: dynloader and PLs [was: plperl intial pass]

Mark Hollomon wrote:

> AHHH, now I understand the difference. By default, the perl installation
> does not create a shared library. It creates a static archive only.
> And the three linux distros that I have experience with don't force
> the creation of the shared lib. So, my situation is:
>
> postgres
> |
> |
> +----------------------+ +-----------------+
> | plperl.so | | Opcode.so |
> | +--------------+ | | |
> | | libperl.a | <-+------------| |
> | +--------------+ | | |
> +----------------------+ +-----------------+
>
> And it is THAT link that I cannot get to happen without the RTLD_GLOBAL
> flag I mentioned.

Yes - we need to understand the differences. After looking at
some perl manpages (perlxs, perlembed, perlmodlib etc.) and
consulting Opcode.pm I see the problems clearer now.

Under Tcl, you can simply type "load <shared-object>" to load
a .so and cause a call to it's ..._Init() function. Whatever
comes there, the .so's ..._Init() function will tell it. And
since every C function that should be callable from Tcl is
given to the interpreter as a function pointer from within
the ..._Init(), nothing except the ..._Init() function itself
must be really resolved. In fact, the functions called from
Tcl can be declared static inside the shared object (what's
true in pltcl) so there are no symbols to resolve.

A safe Tcl interpreter has no load command. But the
controlling C application can call the .so's ..._Init()
function directly to simulate the "load" (well, it should be
the ..._SafeInit(), but that's another story). Thus, a C
application creating a safe interpreter can load modules for
it even if the interpreter itself can't.

Under Perl, a package using a shared object is allways
surrounded by some .pm which tells to lookup symbols via the
dynamic loader (if I understand XSUB's right). So it's still
a type of a script that controls the Perl->C-function
bindings, not the shared object itself.

The detail I don't understand is what breaks Perl's
dynaloader if you use it from inside of plperl.so. Since Perl
isn't built shared, the entire libperl.a should be linked
static into plperl.so. What's the exact error message when
you try to USE Opcode?

>
> Sorry for the confusion.
>
> Hopefully you can help find a way out of this.
>
> I had a patch to change the way dynloader worked on linuxelf,

I don't think you should change the entire dynamic loader of
PostgreSQL for it. This could be a can of worms and you
should be happy that these problems showed up already on your
development platform. I don't expect that you're willing to
fix the dynamic loading under AIX, HP-UX and Solaris too
(maybe you can't because the lack of appropriate
environment).

> but over night my disk crashed. brand new UDMA/66 drive. Grrrr.

Ech

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #