Hello,
One of our Customer is getting Coredump when our application is trying to load a library(one of our products library) using dlopen() on AIX 6.1.
Our application and our shared library are built on AIX 5.3 machine using xlC compiler.
we have tried executing the same application on our in-house AIX 6.1 machine and we didn't get any issues . Everything working fine.
Problem is with the Customer's Environment.
Customer OSlevel is 6100-02
Here is the stack trace. It shows, core dump occured in __Init().
we have used dlopen as
Could you let me know what could be the problem.
Is this a know issue OR Customer Machine is missing any filesets.
Thanks in advance.
regards,
Srikrishna Erra.
Moderator's Comments:
Use code tags please, ty.
Last edited by zaxxon; 06-14-2010 at 12:25 PM..
Reason: code tags
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)
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)
Hi
Where is the default location of libs to search, when we specify any lib in dlopen function.
And if we want to specify a custom location, how will we do it?
thanks. (1 Reply)
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)
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)
Hi,
I created two library libsum.so and libproduct.so. In the libproduct.so is defined function "product" that use function "sum" defined in libsum.so. So libproduct depends on libsum.
In main function I called product function by a dlopen request. Unfortunaly, when I execute program I have an... (5 Replies)
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)
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... (3 Replies)
Discussion started by: rfkrakora
3 Replies
LEARN ABOUT OSF1
dlclose
dlclose(3) Library Functions Manual dlclose(3)NAME
dlclose - Close a dlopen() object
SYNOPSIS
#include <dlfcn.h>
int dlclose(void *handle)
PARAMETERS
A pointer to a global symbol object that is returned from a call to dlopen().
DESCRIPTION
The dlclose function is used to inform the system that the object referenced by a handle returned from a previous dlopen() invocation is no
longer needed by the application.
The use of dlclose() reflects a statement of intent on the part of the process, but does not create any requirements on the dynamic library
loader, such as removal of the code or symbols referenced by handle. Once an object has been closed using dlclose(), an application should
assume that its symbols are no longer available to dlsym(). All objects loaded automatically as a result of invoking dlopen() on the refer-
enced object are also closed.
The dlclose function deallocates the address space for the library corresponding to handle. The results are undefined if any user function
continues to call a symbol resolved in the address space of a library that has since been deallocated by dlclose.
The dlclose operation will not remove an object to which references have been relocated, until or unless all such references are removed.
For instance, an object that had been loaded with a dlopen() operation specifying the RTLD_GLOBAL flag might provide a target for dynamic
relocations performed in the processing of other objects - in such environments, an application may assume that no relocation, once made,
will be undone or remade unless the object requiring the relocation has itself been removed.
RETURN VALUE
If the referenced object was successfully closed, dlclose() returns 0. If the object could not be closed or if handle does not refer to an
open object, dlclose() returns a non-zero value. More detailed diagnostic information will be available through dlerror().
ERRORS
No errors are defined.
NOTES
The dlopen and dlclose routines might dynamically change the resolution of certain symbols referenced by a program or its shared library
dependencies. The dlopen routine might resolve symbols that were previously unresolved, and dlclose might cause resolved symbols to become
unresolved or to be reresolved to a different symbol definition.
A portable application will employ a handle returned from a dlopen() invocation only within a given scope bracketed by the dlopen() and
dlclose() operations. The dynamic library loader is free to use reference counting or other techniques such that multiple calls to
dlopen() referencing the same object may return the same object for handle. The dynamic library loader is also free to re-use a handle. For
these reasons, the value of a handle must be treated as an opaque object by the application, used only in calls to dlsym() and dlclose().
RELATED INFORMATION dlerror(3), dlopen(3), dlsym(3). delim off
dlclose(3)