problem with dynamic loading of shared library
Roger Reynolds
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.
Tim Docker
In article pe...@best.com (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.
>
> 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
ti...@zeta.org.au
---------------------
Alexander Damisch
Tim Docker wrote:
...
> 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=======
Alexander Maria Damisch E-mail (MIME): al...@takefive.co.at
TakeFive Software Tel: +43 662 457915
Jakob-Haringer-Strasse 8 Fax: +43 662 4579156
A-5020 Salzburg in...@takefive.co.at
TakeFive Software Inc.
20823 Stevens Creek Blvd
USA-Cupertino, CA, 95014 in...@takefive.com
Alexandre Oliva
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
mailto:ol...@dcc.unicamp.br mailto:aol...@acm.org
Universidade Estadual de Campinas, SP, Brasil