[PyKDE] FYI, Things we learned, when trying to load SIPed shared libraries.
Stephan Koerner
skoer at adams.com
Fri Aug 24 17:59:12 BST 2001
Just thought I'd share some of our experiences with the chance it might
help someone else.
stephan
Revised: 2001-08-23
Subject: Things we learned, when trying to load SIPed shared libraries.
When faced with an Import Error or core dump upon an import, the following
where a few steps we found helpful to track down shared library loading issues.
1) Fire-up Python with the `-v -v' option just to make certain Python
is importing the module/library you expect it to be picking up.
2) For diagnostic purposes do an import on the library directly rather than
the pure python helper file.
Example: "import libqtc rather than import qt"
3) Take a look inside the SIPed generated library, to see what it depends on.
There are different commands on the respective operating systems
to do this.
AIX `dump -H lib<foo>c.so `
HP-UX `chatr lib<foo>c.sl `
IRIX `elfdump -L lib<foo>c.so `
SunOS `ldd lib<foo>c.so `
NT dumpbin /DEPENDENTS lib<foo>c.dll
the "Dependency Walker" which comes with
the Dev Studio tools is also handy.
4) Shared Library paths?
On the various operating systems the loaders often take cues from
environment variables to find shared libraries.
This bares investigation, only after you are certain that Python is
finding the SIPed library properly and now you are fighting an issue
that the SIPed library is trying to pull in another library.
(Python finds the initial SIPed shared library by way of the normal
python path search)
The following are some of the environment variables the loaders reference.
AIX $LIBPATH
HP-UX $SHLIB_PATH
IRIX $LD_LIBRARY_PATH, $LD_LIBRARYN32_PATH
SunOS $LD_LIBRARY_PATH
`env | grep LIB`
5) What's really happening when the loader is trying to pull in
lib<foo>c.s[ol] but fails. It seems some operating systems
offer a clue as to why a load may have failed, others don't
offer as much information as desired.
To help diagnose what might be happening try the following.
Example is for AIX.
- create a dummy main() with nothing in it ( foo.cxx)
echo 'int main(int argc, char **argv){return 1;)} > foo.cxx
- Link this against the library in question
xlC foo.cxx libqtcmodule.so
- Run the resulting executable
./a.out
- Watch all those unresolved symbols scroll by
- This operation might highlight what subordinate libraries might have
problems being loaded.
Saga:
The following are a couple things which happened to us on the way to
getting a SIPed-PyQt application running. This application uses PyQt
and we generate our own SIPed modules/libraries. So you will see
in our application
import qt # which then import libqtcmodule.s[ol]
import ourCompiledCode # which then import libourCompiledCode.s[ol]
.
.
Scenario 1)
We could import the respective modules/libraries individually but not
together. If both where imported python would core dump.
The respective libraries libqtcmodule.sl and libourCompiledCodec.sl
where loading two different libsip.sl libraries. (One library was
picking up the libsip.sl from the build environ and the other was
picking it up from the release environ) (I hate it, when that happens;-)
Combination of using `chatr` and the `dde` debugger helped track this
problem down. (Depending on how you link the .sl there might be an
internal reference with a full file spec pointing to it's dependent
libraries. Hence the `chatr` command comes in handy. ) (Try looking
at the HP-UX link option +cdp )
Scenario 2)
Under AIX use the -brtl option on the link command otherwise the
libraries won't look for .so files to pull in.
Thanks to:
The person that posted there steps in
hpux_install_notes.txt and solaris_install_notes.txt
If anyone remembers who this was could you send me there e-mail address
Prepared: skoer at adams.com
End:
--
More information about the PyQt
mailing list