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@debis.com (Jan Wieck) #