Well

so.c

bool testFn(void)
{
   return true;
}

compiling... output shared object called test.so

and then (wanna know symbols) bash> nm test.so

0000135c A _DYNAMIC
0000134c A _GLOBAL_OFFSET_TABLE_
000013ac A __bss_start
000013ac A _edata
000013ac A _end
0000030c T testFn__Fv

what is the suffix "__Fv" means... because of it the funstion dlsym returns NULL in response of

bool (*fn)();
fn = (bool (*)()) dlsym("abs_path_to_test.so", "testFn");

Briefly:

fn equals NULL because of no such symbol found in "test.so". Yes, there "testFn__Fv" instead of "testFn"... But why ? What is "__Fv" means & how can I prevent it's appearence...

tnx

• RE: using dlsym (FreeBSD 4.5),Soldier, 07:03 , 03-Апр-02
  • well,uin, 12:52 , 04-Апр-02
  • in details,uin, 19:35 , 04-Апр-02
    • RE: in details,Soldier, 07:13 , 05-Апр-02
      • no,uin, 14:14 , 05-Апр-02
        • RE: no,Soldier, 15:04 , 05-Апр-02
          • First,uin, 16:18 , 05-Апр-02
            • Done,uin, 18:01 , 05-Апр-02
              • How to use C++ classes  via dynamic loaded library,Soldier, 08:50 , 07-Апр-02
                • thank u,uin, 18:34 , 08-Апр-02
            • RE: First,Soldier, 21:10 , 06-Апр-02

>Well
>
>so.c
>
>bool testFn(void)
>{
>   return true;
>}
>
>compiling... output shared object called test.so
>
>
>and then (wanna know symbols) bash> nm test.so
>
>0000135c A _DYNAMIC
>0000134c A _GLOBAL_OFFSET_TABLE_
>000013ac A __bss_start
>000013ac A _edata
>000013ac A _end
>0000030c T testFn__Fv
>
>what is the suffix "__Fv" means...
>because of it the funstion
>dlsym returns NULL in response
>of
>
>bool (*fn)();
>fn = (bool (*)()) dlsym("abs_path_to_test.so", "testFn");
>
>
>Briefly:
>
>fn equals NULL because of no
>such symbol found in "test.so".
>Yes, there "testFn__Fv" instead of
>"testFn"... But why ? What
>is "__Fv" means & how
>can I prevent it's appearence...
>
>
>tnx

This is because you are using C++ compiler and this language allows so called overriding. It means that you may define functions with same name but with diffirent types of parameters. To distinct such functions this suffix __?? is used. In your case testFn__Fv means testFn - far function with no arguments. If you define it like testFn(int) than you will see testFn_Fi symbol and so on.

So use testFn_Fv instead of testFn or use C compiler instead of C++ one.

thank u, but how can I use classes ? (export/import. not objects but classes: class CTest for example. is it possible ?)

tnx

Suppose, I have a multithreaded application (daemon) and a global pointer to some function described in 'so'. Why the following does not work (SIGSEGV've been sended) ?

int (* fn)();

void foo()
{
//***

  fn = (int (*)()) dlsym(handle_to_opened_so, "func name");
  // returns ok

//***
}

void * thr_routine(void * _arg_p)
{
  //***
    (*fn)(); // <- SIGSEGV
  //***
   return NULL;
};

>Suppose, I have a multithreaded application
>(daemon) and a global pointer
>to some function described in
>'so'. Why the following does
>not work (SIGSEGV've been sended)
>?
>
>int (* fn)();
>
>void foo()
>{
>//***
>
>  fn = (int (*)())
>dlsym(handle_to_opened_so, "func name");
>  // returns ok
>
>//***
>}
>
>void * thr_routine(void * _arg_p)
>{
>  //***
>    (*fn)(); //
><- SIGSEGV
>  //***
>   return NULL;
>};

If realy everything OK it should work and  I have two suggestions why it not:
1. You are using dlopen after creating of thread (you MUST use it before).
2. Problem in implementation of 'func_name'

As to previous question - sorry, but I do  not know how to use classes defined in dynamicaly loaded library directly (I used some ugly methods to do that), but why do not use this library as a shared? In this case there are no problems.

Anyway, I will try to find out solution at weekends and if I succeed I will share results with you.

sequence of actions:

1. obtaining the global (!) handle of 'so' (it's ok)
2. obtaining the global (!) poiter to some foo (it's ok)
3. for each thread (in thr_routine) call the 'some foo' talking above.
4. SIGSEGV

the problem is that an appearece of kernel action number 4 terminates the programm (core dumped).

Ok. Lets clear situation.

I suppose you are using libpthread. In this case, a sequence

dlopen -> dlsym -> pthread_create

should work properly

and sequence:
pthread_create -> dlopen -> dlsym
or
.... -> pthread_create -> dlsym

should cause segmentation fault (SIGSEGV)

Which sequence is used in you program?

If you only want avoid an aborting of your program at receiving signal SIGSEGV, just catch this signal and  it is all.

assuming that it's impossible to catch SIGSEGV. I do not wanna to explain such assumption (it's too long), but take it into account please.

I solved my problem. thank u.

If still actually:
http://www.vidler.clara.net/dynamic.html
I tested it and it works.

Best

COM like

>assuming that it's impossible to catch
>SIGSEGV

In Linux ( I think in another *nix-es too) it possible. Of course you should teminate your program (using exit, for example) on catching this signal but you have possibility to settle some things down.

>I do not wanna
>to explain such assumption (it's
>too long), but take it
>into account please.