Sponsored Content
Full Discussion: dlopen Linux vs. OSX
Top Forums Programming dlopen Linux vs. OSX Post 302480018 by rfkrakora on Monday 13th of December 2010 07:11:21 PM
Old 12-13-2010
dlopen Linux vs. OSX

I've got a C++ program and some plugins ( shared objects ) that I have been developing for Linux. I was originally using and OSX machine to develop and test most of the code.

I use dlopen to open the shared objects and then call methods from them. It behaves differently on Linux ( don't know the version right now, have to check tomorrow ) vs. OSX ( 10.6 ).

The plugins are the same class & methods exactly, except for a method that returns the plugin name ( see below ).

Code:
namespace plugin
{
class child : public parent
{
...
std::string pluginName()
{
   return "plugin1";
}
...
};
}

extern "C" void Init( plugin::pluginAPI *pApi )
{
   parent *parent = new child();
   pApi->plugin( parent );
}

namespace plugin
{
class child : public parent
{
...
std::string pluginName()
{
   return "plugin2";
}
...
};
}

extern "C" void Init( plugin::pluginAPI *pApi )
{
   parent *parent = new child();
   pApi->plugin( parent );
}

My main() does dlopen on each of them, finds an Init() method and calls the init method for each, passing a pointer to an api class so Init() can give main() back a handle to the plugin ( via the parent base ).

When main() calls parent->pluginName(), on OSX, it always returns "plugin1" no matter which handle is used. On Linux, the same code returns "plugin1" when that handle is used and "plugin2" when that handle is used.

Now, the OSX result seems correct to me, because that .so is loaded first, but I would still expect a dlopen error when loading the second one.

I know the proper solution is to have different child class names in each plugin - that is going to happen at some point, but I still would like to figure out why OSX and Linux behave differently in this regard.

I'm investigating this myself, but was wondering if someone can shed any light on this?

Regards,
RK
 

10 More Discussions You Might Find Interesting

1. Solaris

dlopen issue with a dll

HI All, I am trying to use a dll using dlopen but in vain. When I try to ldd that dll it returns no output. Can anybody please tell me how I can load this dll in my process space. PS: ldd -l returns a lot of unsatisfied dependent symbols. Thanks a lot in advance Codeman (0 Replies)
Discussion started by: codeman
0 Replies

2. Programming

dlopen failed!

I can open my so file successfully by calling dlopen directly in my main function. But if I fork a child process, and call dlopen in child process, it failed! I don't know why. Following is my code: #include <stdio.h> #include <errno.h> #include <dlfcn.h> void childFunc(void) { void... (1 Reply)
Discussion started by: virmin
1 Replies

3. Programming

compile error while using dlopen

Hi unix lovers, I am getting error while compile a function which uses dlopen. My code is I am getting error as follows Am I missing something? I think I am missing a lot :-) I am using solaris. Thanks in advance, -Ashish (5 Replies)
Discussion started by: shriashishpatil
5 Replies

4. Programming

resolve_symbols: loader error: dlopen:

when i try to run an executable i got the following error message: resolve_symbols: loader error: dlopen: what does this error mean and what should be done to avoid this? with regards (1 Reply)
Discussion started by: gfhgfnhhn
1 Replies

5. Programming

dlopen help

//foo.c #include<stdio.h> int pen(int a) { printf("%d",a); } $cc -c foo.c $ls -shared -o libfoo.so foo.o ///////////now libfoo.so formed //i have already designed libfoo.so //main.c #include<stdio.h> #include <dlfcn.h> int main() { (2 Replies)
Discussion started by: lookforlohith
2 Replies

6. Solaris

dlopen() on dolaris

Dear experts, please help #include <stdio.h> #include <dlfcn.h> #include <link.h> #include <iostream.h> #include<stdlib.h> #include<errno.h> void main() { printf("\n in the main\n"); void *handle; handle = dlopen("my.so", RTLD_LAZY); if( handle ==... (2 Replies)
Discussion started by: vin_pll
2 Replies

7. UNIX for Advanced & Expert Users

Help with porting a linux SNC driver to OSX

Hi guys! I'm a regular joe, so this thread might be in the wrong section and if I appear dumb it mostly because I am..and have lack of knowledge about the unix world. :) Please move the tread if needed. To the problem. We are allot of people in the OSx86 community that need a linux driver... (0 Replies)
Discussion started by: Blackshore
0 Replies

8. Programming

Sending emails in C program for multiple machines on Linux/OSX

Hey guys, i am creating a tool that'll run a couple network test, generate a report then email the report. Now i a bit stuck with the email sending part... I tried at first a script which worked on some machines but then it'll work fine on some machine and act up on others... I can't really rely... (2 Replies)
Discussion started by: Jess83
2 Replies

9. Programming

Linux: dlopen fails to find symbols

I've attached a tar.gz containing three tests to demonstrate the problem I'm having. Within the tar are two shared libraries, two test applications, and a Makefile that builds the three tests. The shared libaries are libshlib1.so and libshlib2.so. Both export a function, libFunc, which takes... (5 Replies)
Discussion started by: DreamWarrior
5 Replies

10. Shell Programming and Scripting

Flash And Fade DEMO For Mac OSX 10.7.5, (And Linux?).

This is an AT A GLANCE shell DEMO that does:- 1) 10 centred greyscale fades without warning beeps. 2) 5 centred yellow "WARNING!" flashes with beeps every ON state. 3) 5 FULL widowed red "DANGER!!!" flashes with beeps in the ON and OFF states. It assumes that the warning bell is enabled... (0 Replies)
Discussion started by: wisecracker
0 Replies
DLSYM(3)						     Linux Programmer's Manual							  DLSYM(3)

NAME
dlsym, dlvsym - obtain address of a symbol in a shared object or executable SYNOPSIS
#include <dlfcn.h> void *dlsym(void *handle, const char *symbol); #define _GNU_SOURCE #include <dlfcn.h> void *dlvsym(void *handle, char *symbol, char *version); Link with -ldl. DESCRIPTION
The function dlsym() takes a "handle" of a dynamic loaded shared object returned by dlopen(3) along with a null-terminated symbol name, and returns the address where that symbol is loaded into memory. If the symbol is not found, in the specified object or any of the shared objects that were automatically loaded by dlopen(3) when that object was loaded, dlsym() returns NULL. (The search performed by dlsym() is breadth first through the dependency tree of these shared objects.) Since the value of the symbol could actually be NULL (so that a NULL return from dlsym() need not indicate an error), the correct way to test for an error is to call dlerror(3) to clear any old error conditions, then call dlsym(), and then call dlerror(3) again, saving its return value into a variable, and check whether this saved value is not NULL. There are two special pseudo-handles that may be specified in handle: RTLD_DEFAULT Find the first occurrence of the desired symbol using the default shared object search order. The search will include global sym- bols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag. RTLD_NEXT Find the next occurrence of the desired symbol in the search order after the current object. This allows one to provide a wrapper around a function in another shared object, so that, for example, the definition of a function in a preloaded shared object (see LD_PRELOAD in ld.so(8)) can find and invoke the "real" function provided in another shared object (or for that matter, the "next" definition of the function in cases where there are multiple layers of preloading). The _GNU_SOURCE feature test macro must be defined in order to obtain the definitions of RTLD_DEFAULT and RTLD_NEXT from <dlfcn.h>. The function dlvsym() does the same as dlsym() but takes a version string as an additional argument. RETURN VALUE
On success, these functions return the address associated with symbol. On failure, they return NULL; the cause of the error can be diag- nosed using dlerror(3). VERSIONS
dlsym() is present in glibc 2.0 and later. dlvsym() first appeared in glibc 2.1. ATTRIBUTES
For an explanation of the terms used in this section, see attributes(7). +------------------+---------------+---------+ |Interface | Attribute | Value | +------------------+---------------+---------+ |dlsym(), dlvsym() | Thread safety | MT-Safe | +------------------+---------------+---------+ CONFORMING TO
POSIX.1-2001 describes dlsym(). The dlvsym() function is a GNU extension. NOTES
History The dlsym() function is part of the dlopen API, derived from SunOS. That system does not have dlvsym(). EXAMPLE
See dlopen(3). SEE ALSO
dl_iterate_phdr(3), dladdr(3), dlerror(3), dlinfo(3), dlopen(3), ld.so(8) COLOPHON
This page is part of release 4.15 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/. Linux 2017-09-15 DLSYM(3)
All times are GMT -4. The time now is 12:45 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy