[Python-Dev] LynxOS4 dynamic loading with dlopen() and -ldl (original) (raw)

Martin v. L�wis martin@v.loewis.de
22 Apr 2003 07:40:49 +0200

duane voth <duanev@io.com> writes:

I hacked setup.py to stop "removing" the bad module files and brought up the python interpreter to try the import by hand: [...] (btw, it would be nice if 'ImportError: Symbol not found: "PyIntType"' was emitted without all the debugging by hand

I strongly recommend to use the Python CVS (to become 2.3) as a baseline for your port. Among other things, it does this already.

PyIntType is declared in Objects/intobject.o and is visible in the python binary (the one doing the dlopen()). I'm not that familiar with dlopen() but shouldn't references from the .so being loaded to the loading program be resolved by dlopen during load?

For executables, this is highly platform dependent - they never consider the case of somebody linking with an executable; they expect that symbols normally come from shared libraries.

On ELF systems, it is supported, but still depends on the linker. For example, the GNU linker wants --export-dynamic as a linker option in order to expose symbols from the executable. You can use "nm -D --defined-only" (for GNU nm) to find out whether the executable exports symbols dynamically.

Running nm on 'python' gives '004d2d3c D PyIntType' so all the python symbols are being exported properly.

You are looking into the wrong section :-( Try strip on the binary and see the symbols go away. On ELF systems, you need the .dynsym/.dynstr sections on the binary.

LynxOS seems to shy away from shared libraries (they live in a special nonstandard directory and not all libraries have shared versions). Should I be thinking about doing a static python? If so, I will need to abandon dlopen() completely right? But I also want to use tkinter and the X11 libs to so I don't think static is really what I want!

It depends. I have a strong dislike towards shared libraries, myself. They are hard to use and somewhat inefficient, both in terms of start-up time, and in terms of memory usage. OTOH, for Python extension modules, they simplify the build and deployment process, and help to cut dependencies to other libraries.

So if you can make it work, you should. You can then still consider integrating as many modules as reasonable into your python interpreter image, by means of Setup, and, for an embedded system, you definitely should also do that.

Add demand paging to the picture: If the system has demand-paging, the size of the binary is irrelevant, as the system will swap in only what is needed. If the system needs to read the entire image into RAM, you want it as small as possible, though.

Regards, Martin