Re^3: What's happened to Yaswi?

[Anonymous Monk]

I think adjusting LD_LIBRARY_PATH won't help here, as the problem rather seems to be that .../Low.so isn't even linked against the Prolog library libswipl.so in the first place (which then of course leads to the "undefined symbol: PL_open_foreign_frame" error).

If that were the case, there would be no .so file generated, there would be no .so file to try to load

[Eliya]

If that were the case, there would be no .so file generated

That's not correct. The above link command would surely create the Low.so file (which is the XS binding), but that library won't have libswipl.so listed as a dependency.  In other words, the dynamic linker wouldn't even go looking for the latter library, no matter what LD_LIBRARY_PATHs you tell it to look in...

[Anonymous Monk]

That's not correct.

Except that it is

The linker goes looking for PL_open_foreign_frame just like the dynamic linker

[Eliya]

Except that it isn't :)   Have you actually tried it?

Here's a simple example that mimics what's going on:

// foo.c
// represents the XS lib referencing a symbol (lgamma) in an external 
+library libm.so

#include <math.h>

double foo() {
    return lgamma(42.0);
}


// mytest.c
// this is just a wrapper which essentially does what perl/DynaLoader 
+is doing,
// i.e. loading the XS lib (Foo.so) dynamically at runtime

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

int main()
{
    double (*foo)(void);
    char *error;

    printf("dynamically loading 'Foo.so'...\n");
    
    void *so = dlopen("Foo.so", RTLD_LAZY);
    if (!so) {
        fprintf(stderr, "%s\n", dlerror());  exit(1);
    }
    dlerror();

    *(void **) (&foo) = dlsym(so, "foo");

    if ((error = dlerror()) != NULL)  {
        fprintf(stderr, "%s\n", error);  exit(1);
    }

    printf("%f\n", (*foo)());
    dlclose(so);
    exit(0);
}

Run the following commands

gcc -c -fPIC foo.c                      # compile
gcc -shared -o Foo.so foo.o             # create/link shared library F
+oo.so

gcc -rdynamic -o mytest mytest.c -ldl   # create wrapper executable wh
+ich loads Foo.so

Note that there are no errors while linking Foo.so, even though the command is missing the appropriate link instruction -lm referencing the math library!  As I pointed out, the shared library is created just fine.

Now, if you try to execute it you get the expected "undefined symbol" error at runtime:

$ LD_LIBRARY_PATH=. ./mytest
dynamically loading 'Foo.so'...
./mytest: symbol lookup error: ./Foo.so: undefined symbol: lgamma

while if you link Foo.so with -lm (which corresponds to the step missing in the OP), everything works fine:

$ gcc -shared -o Foo.so foo.o  -lm
$ LD_LIBRARY_PATH=. ./mytest
dynamically loading 'Foo.so'...
114.034212