dlopen: I'm stumped

Hello all,

Attached is my attempt at calling dlopen() from Pharo, and it is not going well.  The C code below works as expected, so the problem has to be either in my code or something in Pharo or the VM itself.

I am fairly certain that loading the attached is safe, but

                DynamicLinkingLibrary
                        getProcAddress:'cos'
                        from:'libm.so'.

crashes the vm in my experience.  Any ideas?

Bill



/*
        http://www.unix.com/man-page/All/3/dlopen/

        Build as:

                gcc -rdynamic -o fubar fubar.c -ldl
*/

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

       int
       main(int argc, char **argv)
       {
           void *handle;
           double (*cosine)(double);
           char *error;

           handle = dlopen("libm.so", RTLD_LAZY);
           if (!handle) {
               fprintf(stderr, "%s\n", dlerror());
               exit(EXIT_FAILURE);
           }

           dlerror(); /* Clear any existing error */

           /* Writing: cosine = (double (*)(double)) dlsym(handle, "cos");
              would seem more natural, but the C99 standard leaves
              casting from "void *" to a function pointer undefined.
              The assignment used below is the POSIX.1-2003 (Technical
              Corrigendum 1) workaround; see the Rationale for the
              POSIX specification of dlsym(). */

           *(void **) (&cosine) = dlsym(handle, "cos");

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

           printf("%f\n", (*cosine)(2.0));
           dlclose(handle);
           exit(EXIT_SUCCESS);
       }

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sorry for any duplication, but this should be visible by now (I think).




-----Original Message-----
From: Schwab,Wilhelm K
Sent: Friday, April 02, 2010 7:24 AM
To: [hidden email]; [hidden email]
Subject: dlopen: I'm stumped

Hello all,

Attached is my attempt at calling dlopen() from Pharo, and it is not going well.  The C code below works as expected, so the problem has to be either in my code or something in Pharo or the VM itself.

I am fairly certain that loading the attached is safe, but

                DynamicLinkingLibrary
                        getProcAddress:'cos'
                        from:'libm.so'.

crashes the vm in my experience.  Any ideas?

Bill



/*
        http://www.unix.com/man-page/All/3/dlopen/

        Build as:

                gcc -rdynamic -o fubar fubar.c -ldl
*/

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

       int
       main(int argc, char **argv)
       {
           void *handle;
           double (*cosine)(double);
           char *error;

           handle = dlopen("libm.so", RTLD_LAZY);
           if (!handle) {
               fprintf(stderr, "%s\n", dlerror());
               exit(EXIT_FAILURE);
           }

           dlerror(); /* Clear any existing error */

           /* Writing: cosine = (double (*)(double)) dlsym(handle, "cos");
              would seem more natural, but the C99 standard leaves
              casting from "void *" to a function pointer undefined.
              The assignment used below is the POSIX.1-2003 (Technical
              Corrigendum 1) workaround; see the Rationale for the
              POSIX specification of dlsym(). */

           *(void **) (&cosine) = dlsym(handle, "cos");

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

           printf("%f\n", (*cosine)(2.0));
           dlclose(handle);
           exit(EXIT_SUCCESS);
       }

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

So Bill, what you are trying to do?
Both Alien and FFI allow you to open an arbitrary executable/library/etc.  Then let you setup and call and retrieve data from any exported procedure within the binary, so you need to recreate that functionality because?

On 2010-04-02, at 5:55 AM, Schwab,Wilhelm K wrote:
--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project