Re: Help with nlffi

Hi (again) :-),

brian wrote:
> I'm not sure what's going on but I'm 99% sure that your nlffi set-up  is 
> correct.
> 
> So that would mean that something is wrong in the creation of the .so  
> file whic is in turn causing the the dynamic load to fail.

You were completely accurate in your diagnosis.

> Look at the objdump utility.  You should be able to use it to check  the 
> contents of the .so file you created and make sure that bertrand  is in 
> there.  I _think_ it's objdump -t ?

Yes, objdump -t is correct, but more friendly output can be obtained 
with nm (at least under a x86-linux system).

> Also try out ldd on the .so file and make sure that it is not  
> referencing an unresolved library, i.e. maybe your LDPATH is not set- up 
> correctly.
> 
> Also, try the following to create you shared library :
> 
> gcc -shared -Wall -pedantic -DPOLKA_NUM=3 polka.c -o polkagmp.so -lgmp

I tried building the library with the command shown above and using 'nm' 
  I found out that there were "unresolved symbols" inside my .so.
Here I paste the output of nm in order to show for future requesters 
(all the "U" labeled lines means "The symbol is undefined"):

bn@DALI:~/tesis/nlffi-tests/polka$ nm polkagmp.so
00000798 T bertrand
00001b84 A __bss_start
000006b0 t call_gmon_start
00001b84 b completed.1
00001a7c d __CTOR_END__
00001a78 d __CTOR_LIST__
          w __cxa_finalize@@GLIBC_2.1.3
00000a20 t __do_global_ctors_aux
000006e0 t __do_global_dtors_aux
00001b7c d __dso_handle
00001a84 d __DTOR_END__
00001a80 d __DTOR_LIST__
00001a8c A _DYNAMIC
00001b84 A _edata
00001b88 A _end
00000a50 T _fini
00000750 t frame_dummy
00000a74 r __FRAME_END__
00001b68 a _GLOBAL_OFFSET_TABLE_
          w __gmon_start__
          U __gmpz_set_ui
00000660 T _init
00001a88 d __JCR_END__
00001a88 d __JCR_LIST__
          w _Jv_RegisterClasses
00001b80 d p.0
00000a6c r polka_cst
          U polka_dec
00000a70 r polka_eps
          U polka_finalize
          U polka_initialize
          U poly_assign_variables
          U poly_free
          U poly_print
          U poly_universe
          U vector_alloc
          U vector_free

So I re-compiled with the following:

   gcc -shared -Wall -pedantic -DPOLKA_NUM=3 polka.c -o polkagmp.so 
-lgmp -lpolkag

and another run of nm only showed a few unresolved symbols like these:

          U stderr@@GLIBC_2.0
          U stdout@@GLIBC_2.0
          U strlen@@GLIBC_2.0

but no "U" for symbols under the library of my interest. So I tried the 
"sml -m polka.cm" and it work!

> As I said, I'm pretty sure your nlffi set-up is correct.  Something  is 
> wrong with the dynamic library.
> 
> This format:
> 
>>   structure LibH = struct
>>     local
>>       val lh = DynLinkage.open_lib
>>               { name = "./polkagmp.so", global = true, lazy = true }
>>     in
>>         fun libh s = let
>>           val sh = DynLinkage.lib_symbol (lh, s)
>>         in
>>           fn () => DynLinkage.addr sh
>>         end
>>     end
>>   end
> 
> 
> Is what I always use.  You might want to use the absolute pathname  for 
> the library rather than the relative pathname.

Thank you very much. Are you on the dev team? 'cause if you're I'd like 
to ask you to include some of these tips in some README or tutorial for 
nlffi.

Once again, thanks for your time and answers.
Bests, Natalia.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642