dynamic linking and g++

kris273 · 08-06-2004, 03:15 AM

my problem is when doing dynamic linking and loading, it seems I HAVE to use the gcc command.

My question is:

Is this a bug
some compability issue I don't know about g++/gcc
is there something different I should be doing.

Quote:

code:
dlload.c

#include <dlfcn.h>

int main(int argc, char **argv)
{
void *lib;
void (*fn)();

if(argc != 2) return -1;

lib=dlopen(argv[1], RTLD_LAZY);
fn=dlsym(lib, "hello");

fn();

dlclose(lib);
return 0;
}

hello.c

code:#include <stdio.h>

void hello()
{
printf("Hello\n");
}

gcc -o dlload dlload.c -ldl
gcc -shared -fPIC -o hello.so hello.c

how ever, this does not seem to work if I use, is there a way to fix this?

g++ -shared -fPIC -o hello.so hello.c (yes it does complie)
run the program and i get "undefined symbol: hello "

Hko · 08-06-2004, 04:16 AM

Quick guess:

1) Make sure the dynamic lib (.so) is in a directory listed in /etc/ld.so.conf. Either add the directory to this file or copy the .so to a directory that is already listed in /etc/ld.so.conf.

2) Then run "ldconfig" (as root).

3) Then try again to run your program.

kris273 · 08-06-2004, 05:04 PM

Code:

//dynamic.c

#include <stdio.h> /*for printf() */
#include <stdlib.h> /* for exit() */
#include <dlfcn.h>

 typedef void (*pf)();
int main()
{
 
 void *lib;
 pf greet;
 const char * err;

 lib=dlopen("./hello.so", RTLD_NOW);
 if (!lib)
 {
  printf("failed to open hello.so: %s \n", dlerror());
  exit(1);
 }
 dlerror(); /*first clear any previous error; redundant
            in this case but a useful habit*/
 greet= (pf) dlsym(lib, "hello");/*locate hello() */
 err=dlerror();/*check for errors and copy error message*/
 if (err)
 {
  printf("failed to locate hello(): %s \n", err);
  exit(1);
 }
 greet(); /*call hello() */
 dlclose(lib);
 return 0;
}

//hello.c

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

//#include <string.h>
//using namespace STD;

//gcc -shared -fPIC hello.c -o hello.so
void hello()
{
 printf("have a nice day.\n");
  printf("or a bad day what ever you choose\n");

}

here's what i typed:

$ g++ -o test dynamic.c -ldl
$ gcc -shared -fPIC hello.c -o hello.so
$ ./test
have a nice day.
or a bad day what ever you choose
$ g++ -shared -fPIC hello.c -o hello.so
$ ./test
failed to locate hello(): ./test: undefined symbol: hello
$

foo_bar_foo · 08-06-2004, 05:53 PM

i think one obvious thing is that nothing you have there is in c++
it is all in c.
check this out.

kris273 · 08-06-2004, 08:56 PM

yeah, in that sample I have nothing C, but I want to use strings and cout in the shared libraries (and a few other c++ functions), which as far as I know gcc won't allow it.

aiza · 08-06-2004, 10:09 PM

Quote:

Originally posted by kris273

Code:

//dynamic.c #include <stdio.h> /*for printf() */ #include <stdlib.h> /* for exit() */ #include <dlfcn.h> typedef void (*pf)(); int main() { void *lib; pf greet; const char * err; lib=dlopen("./hello.so", RTLD_NOW); if (!lib) { printf("failed to open hello.so: %s \n", dlerror()); exit(1); } dlerror(); /*first clear any previous error; redundant in this case but a useful habit*/ greet= (pf) dlsym(lib, "hello");/*locate hello() */ err=dlerror();/*check for errors and copy error message*/ if (err) { printf("failed to locate hello(): %s \n", err); exit(1); } greet(); /*call hello() */ dlclose(lib); return 0; } //hello.c #include <stdio.h> #include <stdlib.h> //#include <string.h> //using namespace STD; //gcc -shared -fPIC hello.c -o hello.so void hello() { printf("have a nice day.\n"); printf("or a bad day what ever you choose\n"); }

here's what i typed:

$ g++ -o test dynamic.c -ldl
$ gcc -shared -fPIC hello.c -o hello.so
$ ./test
have a nice day.
or a bad day what ever you choose
$ g++ -shared -fPIC hello.c -o hello.so
$ ./test
failed to locate hello(): ./test: undefined symbol: hello
$

This due to g++ had renamed your function, try with:
extern "C" void hello()
{
....
}

foo_bar_foo · 08-07-2004, 12:12 PM

Quote:

This due to g++ had renamed your function, try with:
extern "C" void hello()
{
....
}

that's exactly what i was trying to say when i said you hadn't written it in c++
c++ compiler encodes extra information about the function into the function name
thanks to aiza for clarifying

kris273 · 08-08-2004, 01:35 AM

I didn't write it in c++?

so if i did everything the same way, and instead of using printf I used cout, and it'll compile it differently thus allowing it to work?

kris273 · 08-15-2004, 01:48 AM

This is the type of function I want.

extern "C" void hello(string input)
{
cout << "hello " << input << endl;
}

how ever the extern C would make it a C only function which makes me unable to use C++ functions. so is there some other way to do it?

deiussum · 08-15-2004, 10:17 AM

No, the extern "C" part just makes the exported symbol use the C naming rules. C++ naming rules mangle the names based on parameters, etc. This is how C++ allows for function overloading. There is nothing about extern "C" that stops you from using C++ code.

Edit: I didn't see before that you also have a string class as a parameter... that MIGHT cause problems trying to export it as extern "C" since it is part of the function prototype. Change that to a char* and it should work, though. Then if you really want a string instead, you can set an instance of the string class to that in the body of the function.

Edit2: Thought I'd clarify a bit more about what your problem is...

When you compile your .so with g++, and your function doesn't have extern "C", the C++ naming rules are used to mangle the name. Then in your executable, you are using dlsym to try and load an UNmangled name for the function, which it won't find because the name was mangled. If you can find out what the resulting mangled name is, you could theoretically pass that as the name to dlsym instead. Since that is kind of an ugly solution, it is generally just better to use extern "C" to prevent the name mangling in the first place... Hope that helps explain things a bit.

The_Nerd · 08-16-2004, 02:16 PM

Both the .so (library) and your program must be compiled with either C or C++, not both.