Sponsored Content
Top Forums Programming Help building and using a shared object (x64) Post 302614233 by Maelstrom on Wednesday 28th of March 2012 10:58:25 AM
Old 03-28-2012
Help building and using a shared object (x64)

Hello,

I am not that experienced with Linux, and I am currently facing some issues.

The application I'm working on uses hundreds of threads. To optimize the memory usage, I am putting all my data inside a shared object (so).

The steps for this are as follows:

1. a C file (generated from an XML file) with lots of arrays (const char c1[] ="string" and const char* arr_const[] = {"s1", "s2", ...."sN"}, etc.)

2. a shell script to compile this to a shared object:
gcc -g -m64 -Wall -fPIC -c bigfile.c
gcc -m64 -shared -Wl -o <custom_new_name>.so bigfile.o


3. some code (on each thread) to open the shared object and get the refferences to my arrays from the shared object:
void ** handle;
*handle=dlopen (<full_path_to_so>, RTLD_NOW);
char** local_var = (char**) dlsym(*handle, "arr_const");


NOTE: the handles don't get unloaded until my application closes.

Using shared objects is mandatory for two reasons:
- optimized memory usage when launchig thousands of threads
- the ability to create new shared objects from new XML files and adding them to the application after it has been installed on client machines (with the help of text config files).

My problem is that the process described above does not work on my x86_64 CentOS 5.8 (dlopen returns NULL). The entire application is built with 64bit settings.
When using this on CentOS 32bit, with gcc using -m32 instead of -m64 for compiling the shared objects, and building my app with 32bit settings, everything is fine.

Any ideas ?
Thank you
 

10 More Discussions You Might Find Interesting

1. Programming

Does my ld support shared object creation

Hi, I have been trying to create a sharef object on my HP UX 11 machine (HP-UX <myhostname> B.11.00 A 9000/879 ...... two-user license) to create the shared object first I am creating the object file using cc -Aa -c +z dyn.c (I use -Aa and +z as per HP's manual on linkers ) to create the... (0 Replies)
Discussion started by: linuxpenguin
0 Replies

2. Linux

Shared Object File

Hi All, I created the share object file using gcc -shared -fpic mypp.cpp -o myp.so but, pls tell me how to link this .so file to my client program. Thanks (0 Replies)
Discussion started by: sarwan
0 Replies

3. AIX

Shared Object library problem

Hi, When using shared objects on AIX 4.3 i am getting runtime problems. I have a small sample program which links to a shared object libray, oracle and system related libraries. At runtime it fails (gives segmentation fault and coredump ) in one proc file when executing login statement. But... (0 Replies)
Discussion started by: suman_jakkula
0 Replies

4. Programming

calling a shared object from a daemon

Hi I have a multithreaded daemon(server) which will accept connections from various clients and sends back results to them. In order to serve my daemon clients, it has to establish a TCP connection to another server(vendor supplied which is listening on a specific TCP port) and gets the... (11 Replies)
Discussion started by: axes
11 Replies

5. UNIX for Advanced & Expert Users

Issue with shared object in AIX

Hi All, I have a problem with the shared objects setup in AIX. We have a customized shell written by the developers over here. When i issue a MQ Series command (mqsilist) it is giving the error as . All the commands making use of this libImbCmdLib.a.so is failing. But when executed in normal... (1 Reply)
Discussion started by: dhanamurthy
1 Replies

6. Shell Programming and Scripting

Any way to access shared object using shell

Hi, I have created a shared object (abc.so) which has a function sum(int a, int b). Is there any way to load the "abc.so" and use the sum function using shell script.. thanks in advance (2 Replies)
Discussion started by: yhacks
2 Replies

7. AIX

AIX 5.2 C++ shared object issue

Hi all, I am developing an application with two components. One "c" binary and one "C++" shared object. While execution, the shared object crashes out and core dump is created whenever "new" is executed. But if i use malloc this will work perfectly. I tried to use dbx. Below given was... (1 Reply)
Discussion started by: itssujith
1 Replies

8. Programming

Error while running shared object

Hello, While running a c++ shared object on AIX I am facing below error - rtld: 0712-001 Symbol __ct__3ETDFv was referenced from module /bancs/aml/lib/libmonitor.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol etd_insert__3ETDFv was... (3 Replies)
Discussion started by: yatrik007
3 Replies

9. Red Hat

shared object

Hi, I would like to create a shared object ( .so). This shared object 1. uses the functions from a library. 2. Also it should be able to use the global variable in an app To achieve this what should I do ? 1) To use the functions in the library should I give the -ld option while... (1 Reply)
Discussion started by: rvan
1 Replies

10. Programming

Shared Object Question

Hello, I am new to programming shared objects and I was hoping someone could tell me if what I want to do is possible, or else lead me in the right direction. I have a main program that contains an abstract base class. I also have a subclass that I'm compiling as a shared object. The subclass... (13 Replies)
Discussion started by: dorik
13 Replies
dlsym(3C)																 dlsym(3C)

NAME
dlsym - get the address of a symbol in a shared object or executable SYNOPSIS
#include <dlfcn.h> void *dlsym(void *restrict handle, const char *restrict name); The dlsym() function allows a process to obtain the address of a symbol that is defined within a shared object or executable. The handle argument is either the value returned from a call to dlopen() or one of a family of special handles. The name argument is the symbol's name as a character string. If handle is returned from dlopen(), the associated shared object must not have been closed using dlclose(). A handle can be obtained from dlopen() using the RTLD_FIRST mode. With this mode, the dlsym() function searches for the named symbol in the initial object referenced by handle. Without this mode, the dlsym() function searches for the named symbol in the group of shared objects loaded automatically as a result of loading the object referenced by handle. See dlopen(3C) and . The following special handles are supported. RTLD_DEFAULT Instructs dlsym() to search for the named symbol starting with the first object loaded, typically the dynamic executable. The search continues through the list of initial dependencies that are loaded with the process, followed by any objects obtained with dlopen(3C). This search follows the default model that is used to relocate all objects within the process. This model also provides for transitioning into a lazy loading environment. If a symbol can not be found in the presently loaded objects, any pending lazy loaded objects are processed in an attempt to locate the symbol. This loading compensates for objects that have not fully defined their dependencies. However, this compensation can undermine the advantages of lazy loading. RTLD_PROBE Instructs dlsym() to search for the named symbol in the same manner as occurs with a handle of RTLD_DEFAULT. However, this model only searches for symbols in the presently loaded objects, together with any lazy loadable objects specifically identified by the caller to provide the named symbol. This handle does not trigger an exhaustive load of any lazy loadable symbols in an attempt to find the named symbol. This handle can provide a more optimal search than would occur using RTLD_DEFAULT. RTLD_NEXT Instructs dlsym() to search for the named symbol in the objects that were loaded following the object from which the dlsym() call is being made. RTLD_SELF Instructs dlsym() to search for the named symbol in the objects that were loaded starting with the object from which the dlsym() call is being made. When used with a special handle, dlsym() is selective in searching objects that have been loaded using dlopen(). These objects are searched for symbols if one of the following conditions are true. o The object is part of the same local dlopen() dependency hierarchy as the calling object. See the for a description of dlopen() dependency hierarchies. o The object has global search access. See dlopen(3C) for a discussion of the RTLD_GLOBAL mode. The dlsym() function returns NULL if handle does not refer to a valid object opened by dlopen() or is not one of the special handles. The function also returns NULL if the named symbol cannot be found within any of the objects associated with handle. Additional diagnostic information is available through dlerror(3C). Example 1: Use dlopen() and dlsym() to access a function or data objects. The following code fragment demonstrates how to use dlopen() and dlsym() to access either function or data objects. For simplicity, error checking has been omitted. void *handle; int *iptr, (*fptr)(int); /* open the needed object */ handle = dlopen("/usr/home/me/libfoo.so.1", RTLD_LAZY); /* find the address of function and data objects */ fptr = (int (*)(int))dlsym(handle, "my_function"); iptr = (int *)dlsym(handle, "my_object"); /* invoke function, passing value of integer as a parameter */ (*fptr)(*iptr); Example 2: Use dlsym() to verify that a particular function is defined. The following code fragment shows how to use dlsym() to verify that a function is defined. If the function exists, the function is called. int (*fptr)(); if ((fptr = (int (*)())dlsym(RTLD_DEFAULT, "my_function")) != NULL) { (*fptr)(); } The dlsym() function is one of a family of functions that give the user direct access to the dynamic linking facilities. These facilities are available to dynamically-linked processes only. See the . See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Interface Stability |Standard | +-----------------------------+-----------------------------+ |MT-Level |MT-Safe | +-----------------------------+-----------------------------+ ld(1), ld.so.1(1), dladdr(3C), dlclose(3C), dldump(3C), dlerror(3C), dlinfo(3C), dlopen(3C), attributes(5), standards(5) If an object is acting as a filter, care should be taken when interpreting the address of any symbol obtained using a handle to this object. For example, using dlsym(3C) to obtain the symbol _end for this object, results in returning the address of the symbol _end within the filtee, not the filter. For more information on filters see the . 26 Sep 2005 dlsym(3C)
All times are GMT -4. The time now is 11:32 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy