Problems with dynamic libraries (long)

QNX Newsgroups (Archives) qdn.public.qnxrtp.newuser
#1

We plan to use different versions of hardware in some systems to achieve the
same functionality. Therefore, I’ve developed a dynamic library for the
hardware with the idea that as hardware vendors change, I’ll be able to
write a new dynamic library and the rest of my application will not know the
difference. However, I’m having problems using my libraries.
To eliminate the end-user from the messy pointer-to-function stuff required
when using dynamic libraries, I’ve developed a set of proxy libraries that
get statically linked to the client. The client simply opens the dynamic lib
that it wants and gets a handle to it. It then passes this handle to the
proxy libraries which do all the dirty work of calling the actual function.
Now, here’s where my problem begins I think:
I thought that there’s no reason the proxy library couldn’t just be another
implementation of the interface defined by the dynamic libraries.
Therefore, the function names and definitions in the proxy library and the
dynamic library are the same and they both use a common header file to
prototype the functions. Here’s an example to make things more clear I hope.

[File: MyFunction.h]
double MyFunction(void *hDLL, unsigned int intValue, int *intErrorCode);

[File: MyFunction_Proxy.c]
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
#include “MyFunction.h”
double MyFunction(void *hDLL, unsigned int intValue, int intErrorCode) {
typedef double (pFunc_t)(void, unsigned int, int);
pFunc_t pFunc;
dlerror();
pFunc=dlsym(hDLL, “MyFunction”);
return (*pFunc)(hDLL, intValue, intErrorCode);
}

[File: MyFunction_impl.c]
#include “MyFunction.h”
double MyFunction(void *hDLL, unsigned int intValue, int *intErrorCode)
{ return intValue * 10;
}

[File: MyFunction_Client.c]
#include “myfunction.h”
#include <dlfcn.h>
main() {
void *hDLL;
int intErrorCode;
hDLL=dlopen(“libmyfunction.so”, RTLD_NOW);
printf(“The library result is %f\n”, MyFunction(hDLL, 2, &intErrorCode));
}

Obviously my real-case has many more functions in the library, but in the
proxy library I do the same operations for each function. The problem here
is that sometimes after I compile my code I get a segmentation error at
runtime. When I use the debugger, I find that the when the proxy function
attempt to evaluate the function inside the DLL, it instead evaluates
itself, which puts it into an infinite loop and a very quick stack-overflow.
My question is: Shouldn’t this work? Isn’t it OK to have the name of the
proxy function be the same as the name of the function you are looking up
(dlsym) in the dynamic library? I could use different function names in
proxy libraries but then I couldn’t use the same header file for proxy
libraries and the dynamic libraries. Keep in mind, this works sometimes and
sometimes does not. It seems to be a possible problem in the Metroworks
compiler, but before try to chase down the compiler path too far, I just
want to make sure that I’m not trying to do something that is in bad
practice or was not intended to be done that way.

#2

Is the proxy function ever called or linked against a shared lib?

I would think that this should work, but there might be some weird
symbol scope thingy working here.

Can you reproduce the problem in a test case (the one below works fine
for me)

You might try adding -Bsymbolic to the link line of your dynamic lib,
that way it won’t resolve against any external functions.

–
cburgess@qnx.com

#3

In article <aaknkm$989$1@nntp.qnx.com>
cburgess@qnx.com writes:

I would think that this should work, but there might be some weird
symbol scope thingy working here.

I think I read somewhere that dlload() screws if
multiple dlls had the same filename – tho not seems to the case here.

kabe

#4

The thing I don’t understand is why you need this “proxy library”.
What does it buy you?

[File: MyFunction_impl.c]
#include “MyFunction.h”
double MyFunction(void *hDLL, unsigned int intValue, int *intErrorCode)
}

qcc -shared -c MyFunction_impl.c
qcc -shared -Wl,-hlibmyfunc.so -o libmyfunc.so MyFunction_impl.o

And just link you application with:

[File: MyFunction_Client.c]
#include “myfunction.h”
#include <dlfcn.h>
main() {
printf(“The library result is %f\n”, MyFunction(hDLL, 2, &intErrorCode));
}

qcc -c MyFunction_Client.c
qcc -o MyFunction_Client MyFuncton_Client.o -lmyfunc.so

You “MyFunction_Client” will then remember to looking for “libmyfunc.so”
everytime it is loaded, and settle down the MyFunction() point.

You can always replace the “libmyfunc.so”, provided 1) the proto
type of MyFunction() is not change, 2) you don’t change the name
of the library (the -h option passed to linker).

-xtang

Chris Rose <esorcc@hotmail.com> wrote:

We plan to use different versions of hardware in some systems to achieve the
same functionality. Therefore, I’ve developed a dynamic library for the
hardware with the idea that as hardware vendors change, I’ll be able to
write a new dynamic library and the rest of my application will not know the
difference. However, I’m having problems using my libraries.
To eliminate the end-user from the messy pointer-to-function stuff required
when using dynamic libraries, I’ve developed a set of proxy libraries that
get statically linked to the client. The client simply opens the dynamic lib
that it wants and gets a handle to it. It then passes this handle to the
proxy libraries which do all the dirty work of calling the actual function.
Now, here’s where my problem begins I think:
I thought that there’s no reason the proxy library couldn’t just be another
implementation of the interface defined by the dynamic libraries.
Therefore, the function names and definitions in the proxy library and the
dynamic library are the same and they both use a common header file to
prototype the functions. Here’s an example to make things more clear I hope.

[File: MyFunction.h]
double MyFunction(void *hDLL, unsigned int intValue, int *intErrorCode);

[File: MyFunction_Proxy.c]
#include <stdio.h
#include <stdlib.h
#include <dlfcn.h
#include “MyFunction.h”
double MyFunction(void *hDLL, unsigned int intValue, int intErrorCode) {
typedef double (pFunc_t)(void, unsigned int, int);
pFunc_t pFunc;
dlerror();
pFunc=dlsym(hDLL, “MyFunction”);
return (*pFunc)(hDLL, intValue, intErrorCode);
}

[File: MyFunction_impl.c]
#include “MyFunction.h”
double MyFunction(void *hDLL, unsigned int intValue, int *intErrorCode)
{ return intValue * 10;
}

[File: MyFunction_Client.c]
#include “myfunction.h”
#include <dlfcn.h
main() {
void *hDLL;
int intErrorCode;
hDLL=dlopen(“libmyfunction.so”, RTLD_NOW);
printf(“The library result is %f\n”, MyFunction(hDLL, 2, &intErrorCode));
}

Obviously my real-case has many more functions in the library, but in the
proxy library I do the same operations for each function. The problem here
is that sometimes after I compile my code I get a segmentation error at
runtime. When I use the debugger, I find that the when the proxy function
attempt to evaluate the function inside the DLL, it instead evaluates
itself, which puts it into an infinite loop and a very quick stack-overflow.
My question is: Shouldn’t this work? Isn’t it OK to have the name of the
proxy function be the same as the name of the function you are looking up
(dlsym) in the dynamic library? I could use different function names in
proxy libraries but then I couldn’t use the same header file for proxy
libraries and the dynamic libraries. Keep in mind, this works sometimes and
sometimes does not. It seems to be a possible problem in the Metroworks
compiler, but before try to chase down the compiler path too far, I just
want to make sure that I’m not trying to do something that is in bad
practice or was not intended to be done that way.