mcmahill@mtl.mit.edu wrote:
 >
 > Is there a special trick to make dlopen(), dlsym(),... work on the pmax
 > port?  The reason I'm asking is I'm finishing up a package for scilab-2.4
 > (a powerful, matlab like scientific computation environment) and one of
 > the features is the ability to dynamically, on the fly, link C and/or
 > FORTRAN routines into the program (for speed critical items).  Anyway, I
 > have it all working on i386 and mac68k platforms, but not the pmax
 > (DECstation 5000/200, NetBSD-1.3.1).  Basically dlopen() fails. 

This works better on -current with ld.elf_so, I get from your test:

Calling:  dlopen("ext_lib",RTLD_NOW)
   (RTLD_NOW is #defined to be 2)
dlopen returned 0
dlerror() is: Shared object "ext_lib" not found

or with using explicit "./ext_lib":

Calling:  dlopen("./ext_lib",RTLD_NOW)
   (RTLD_NOW is #defined to be 2)
dlopen returned 536953856
no dlerror() of dlopen() 
calling dlsym(536953856,"_myfn")
dlsym() returned 0
dlerror() is: Undefined symbol "_myfn"

changing "_myfn" to just "myfn" gives:

Calling:  dlopen("./ext_lib",RTLD_NOW)
   (RTLD_NOW is #defined to be 2)
dlopen returned 536953856
no dlerror() of dlopen() 
calling dlsym(536953856,"myfn")
dlsym() returned 537912496
no dlerror() in dlsym().

If your scilab modules need to access symbols from the main program
you need to link the main program with --export-dynamic, as Ross
Harvey told me to do for perl (which works for me now, with dynamic
linking of modules).

Note that the canonical way to build shared objects is described
in bsd.lib.mk and basically is:
	cc -c -fPIC *.c
	ld -x -shared *.o -o module.so
And one can (should?) use -rpath and -soname as well, but that's more
important for normal shared libraries.

  -  Arne H. J.