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

[Martin v. Löwis]

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: "PyInt_Type"'
> 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.

> PyInt_Type 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 PyInt_Type' 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