Assuming no other problems and the symbols complained of 
are from libc this is normally 
due to the dll referring to symbols that are provided statically
in the linktime libc.so and not in the dynamic (runtime linked) libc.so.1.

This works fine for shared libraries that are implicitly loaded ( specified as -l on link line) since the needed static symbols are loaded into the executable.
If the dll is explicitly loaded (using dlload) and the symbols haven't been otherwise referenced in the executable it will fail to resolve the symbol and the dlopen() call will fail with dlerror complaining about symbol resolution.

Such static symbols can be identified as symbols that occur in a nm dump of
/usr/lib/libc.so and that do not occur in one of /usr/lib/libc.so.1

Workarounds are to ensure that the static symbols are referenced in code in the executable that does the dlopen (in an uncalled dummy routine) or (better) to 
pull the static objects from /usr/lib/libc.so and explicitly link them into 
the dll when its generated.

This can be seen in building tcl and TclX. The normal builds work fine using their own interpreters but if the tclX library is tcl loaded from the tcl
interpreter (tclsh) you get a symbol resolution error initially on 
random (and if thats surmounted then getpriority and then _fsync).

heres some partial shell script that makes a tclx dll with the needed static symbols
 
# pull .o's containing needed static symbols from libc.so and put in archive
FILELIST='random.o getpriority.o v3_fsync.o'
ar xv /usr/lib/libc.so $FILELIST
ar qv st_syms.a $FILELIST
rm -f $FILELIST

# make dll with static symbols included
cc -G -o libtclx8.1.so tclXbsearch..o    tclXchmod..o     tclXcmdInit..o \
        .... ( rest of .o's elided) ....
   tclXstring..o     tclXsocket..o    tclXunixCmds..o   tclXutil..o   \
        ./st_syms.a