A weird problem regarding shared libs...

[Venkatakrishnan, V]

This is what I got Googling and it works.........

David Edelsohn writes....

This most likely is due to a GCC bug on AIX which recently was
tracked down.  GCC on AIX will create shared objects which treat the main
program which dynamically loads them as a shared library to supply some
GCC support routines.  If the main program performing the dlopen() or
load() calls was not compiled by GCC (or by G++ if the library was
compiled by G++) then the dynamic loading fails because of unresolved
references.  (The only way to discover this is with the AIX loadquery()
call, not dlerror()).

	To work around this, copy the appropriate libgcc.a library
(/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.2/libgcc.a) to the
directory where the shared object is built and name the library anything
other than "libgcc.a".  Explicitly link the shared object with libgcc.a
along with all of the other normal objects and libraries.  This will
produce extra warnings about duplicate symbols, but will create a fully
self-contained shared object which can be dynamically loaded by any
program.  This problem will be fixed in the next GCC release.

Regards,
Venky

-----Original Message-----
From: John Love-Jensen [mailto:eljay@adobe.com] 
Sent: Thursday, February 14, 2002 3:53 PM
To: Venkatakrishnan, V
Subject: Re: A weird problem regarding shared libs...


Hi V.,

This is NOT part of your problem, but you should note that because you did
not declare your function ...
    extern "C" const char* func();
... (on both sides of the fence) it's actual name will be C++ mangled and
NOT called "func" in the shared object library.

By the way:  what you are doing is called DSO (dynamic shared object
library), as opposed to SSO (static shared object library).

In MS-Windows land, a DLL is typically a SSO.  However, it is possible to
open it explicitly at runtime, in which case it is a DSO.

Apache uses DSO's extensively.

Also, beware throwing exceptions out from a shared object!  GCC 2.95 does
NOT support doing that!  GCC 3.x is supposed to have fixed it, but it relies
heavily on the calling program and the shared object to have the exact same
exception handling paradigm.  There is NO standard ABI for exceptions!  :-(

Sincerely,
--Eljay


On 2/14/02 2:19 PM, "Venkatakrishnan, V"
<V.Venkatakrishnan@channels.usa.xerox.com> wrote:

> Hi,
> I've the following files...
> /***************************/
> /* hello.c */
> #include <stdio.h>
> #include <dlfcn.h>
> void* lib_handle;
> const char* (*funcptr)(void);
> const char* err_msg;
> 
> int main()
> {
> printf("Hello World.\n"); 
> lib_handle=dlopen("./libshared.so",RTLD_LAZY);
> if(!lib_handle)
> {
> printf("Error loading shared library\t %s.\n",dlerror()); return 0;
> }
> else
> {
> (void*)funcptr=dlsym(lib_handle,"func");
> err_msg=dlerror();
> if(err_msg)
> {
> printf("Error getting pointer to export.\n");
> return 0;
> }
> else
> {
> (*funcptr)();    
> dlclose(lib_handle);
> }
> }
> return 1;
> }
> /*************************************/
> 
> /*shrobj.c*/
> #include <stdio.h>
> const char* func(void)
> {
> printf("Printf from shared lib.\n");
> }
> /************************************/
> 
> now when I do the following
> Gcc -c shrobj.c
> Gcc -shared -o libshared.so shrobj.o
> Gcc hello.c -o Hello
> ./Hello
> everything works fine.........
> 
> Now I basically simply rename the files to change their xtension from 
> ".c" to ".C" and then use g++ like
> G++ -c shrobj.C
> G++ -shared -o libshared.so shrobj.o
> G++ hello.C -o Hello
> ./Hello
> gives me this error
> Hello World
> Error loading shared library    Exec format error.
> 
> Any idea why this is happening?  Why exactly am I getting this "Exec 
> format error", how do I rectify it??
> 
> Regards,
> Venky
>