problem with dynamic loading of shared library

problem with dynamic loading of shared library

Post by Roger Reynol » Sat, 08 Feb 1997 04:00:00



Hang on, this gets a little complicated...

I'm having some difficulty using a shared library that
my program (python actually) is trying to load dynamically at run time.

The problem seems to stem from the fact that my shared library
uses "long long" data variables and does some math with them.

I notice that there are undefined references to the following functions:
        __divdi3, __muldi3, __floatdidf, __moddi3
from my shared library.

These routines are not present in any of the /usr/lib/*.so files.
In fact, they are located in the libgcc.a that is part of the gcc installation.

Problem is, I guess, that when I create my shared library, the
libgcc routines don't get linked in, and somehow they are also
omitted from the link of the program (python) since it probably
dosen't use any "long long" stuff.

The relevant components here are  python-1.4 and my shared library,
both built with gcc-2.7.2.1, all running on solaris 2.5.1.

What I was able to do, for an immediate work around, was to add the
following code:

    if (0)
    {
        __divdi3();
        __muldi3();
        __floatdidf();
        __moddi3();
    }

someplace in the main routine for the program (python) that eventually
tries to load my shared lib.  This in fact works, and the resulting
python can load my shared lib (as part of an extension module) and
it works real well.

But, I'd rather find some solution where a standard, unmodified python
executeable is able to load my shared library.

Any tips would be greatly appreciated.

 
 
 

problem with dynamic loading of shared library

Post by Tim Dock » Mon, 10 Feb 1997 04:00:00



Quote:> Hang on, this gets a little complicated...

> I'm having some difficulty using a shared library that
> my program (python actually) is trying to load dynamically at run time.

> These routines are not present in any of the /usr/lib/*.so files.
> In fact, they are located in the libgcc.a that is part of the gcc
> installation.

> ...

> Problem is, I guess, that when I create my shared library, the
> libgcc routines don't get linked in, and somehow they are also
> omitted from the link of the program (python) since it probably
> dosen't use any "long long" stuff.
> executeable is able to load my shared library.

> ...

> Any tips would be greatly appreciated.

I think that you are correct in your analysis above. I got around this
problem though by linking the shared module with libgcc.a. All I had
to do was add a -lgcc to the appropriate line in the module setup
file.

Hope this helps.

--
---------------------
Tim Docker

---------------------

 
 
 

problem with dynamic loading of shared library

Post by Alexander Damisc » Tue, 11 Feb 1997 04:00:00


...

Quote:> to do was add a -lgcc to the appropriate line in the module setup
> file.

> Hope this helps.

In general: you have to link any object/library to your .so
file, as it was an stand-allone executable .

--
                                                 ,,,
                                                (. .)
=============================================ooO=(_)=Ooo=======

TakeFive Software            Tel: +43 662 457915
Jakob-Haringer-Strasse 8     Fax: +43 662 4579156

TakeFive Software Inc.                                
20823 Stevens Creek Blvd                              

 
 
 

problem with dynamic loading of shared library

Post by Alexandre Oliv » Tue, 11 Feb 1997 04:00:00


Quote:Roger Reynolds writes:
> Hang on, this gets a little complicated...
> I'm having some difficulty using a shared library that
> my program (python actually) is trying to load dynamically at run time.
> The problem seems to stem from the fact that my shared library
> uses "long long" data variables and does some math with them.
> I notice that there are undefined references to the following functions:
>    __divdi3, __muldi3, __floatdidf, __moddi3
> from my shared library.
> These routines are not present in any of the /usr/lib/*.so files.
> In fact, they are located in the libgcc.a that is part of the gcc installation.
> Problem is, I guess, that when I create my shared library, the
> libgcc routines don't get linked in, and somehow they are also
> omitted from the link of the program (python) since it probably
> dosen't use any "long long" stuff.

That's right, libgcc is not linked in when a shared library is built,
but this was a mistake, and it should be fixed in the next major
release of gcc.  By now, just add -lgcc to the shared library creation
command line.  If you happen to be writing C++ code, make sure
-lstdc++ -lg++ are before -lgcc.

Regards,

--
Alexandre Oliva

Universidade Estadual de Campinas, SP, Brasil

 
 
 

1. Shared library loading shared library.

  I was wondering if someone could tell me how(if possible) this can be done.

  I am writing a shared library that an executable will load int at runtime.  The
shared library I wrote needs to use symbols and functions from another shared
library that was not part of the link line of the executable.  Is there a way for
a shared library to tell the executable that it needs other library loaded that the
executable didn't link in.

  Is there a command line option to ld when creating a shareed library to use
other libraries?

  Is there a link option for the executable to shared libraries to link in other
shared libraries not in the link line?

Illustration
----------
Executable:
CC -o myProgram *.o -lmyLib

My shared library:
ld -G -b -o libmyLib.so
  ** myLib needs another library libotherLib.so

PS.  I am using SUNWspro CC4.1 compiler.

Thanks for any help,
Greg.

--
Gregory Gee
Nortel ISPN
Phone: (613)763-6175 ESN 393


2. Proxy Server Source Code

3. Shared Library/Object dynamic loading: Portability.

4. real time clock signal

5. Shared libraries and dynamic loading - again

6. Bug in quota patch?

7. Dynamic loading of shared library?

8. Can't cu my modem

9. unable to compile dynamic loading or shared libraries on Linux

10. shared libraries, dynamic loading

11. dynamic loading and shared libraries on AIX (Really wierd, man!)

12. Shared Library/Object dynamic loading: Portability.

13. error in loading shared libraries: libXmu.so.6: cannot open shared object