[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sizeof(long) (was: Re: looking for fix to AMD64 python dl problem....)



Hi all

I'm the said developer. Looks like my replies (via Google Groups)
haven't been getting through. And I also went across town for a load
of firewood. So you didn't scare me off :-) So, I'll try to summarise
what I have tried to send in previous mails.

Firstly, 'dl' is not an ugly hack, which I'll explain:

'dl' is not an ugly hack because it provides the RTLD_* constants are
are required by sys.setdlopenflags() in order to change the behaviour
of Python's 'import' statement. There is not other way of doing this,
so 'dl' is required in any Python-wrapped application that involves a
plugin architecture in the wrapped C or C++ (etc) code. The reason (as
I sort-of understand it) is that the symbols in the imported python
module need to be made available to further shared objects that are
loaded from inside the C module. For this to happen, python needs to
instruct the native dlopen functionality to open the .so in a
particular way. Python modules are just special .so files. So it's
necessary to be able to access the dl.RTLD_* flags in order to do
that.

Here is the code we use:

import sys
if platform.system() != "Windows":
    import dl
    # This sets the flags for dlopen used by python so that the
symbols in the
    # ascend library are made available to libraries dlopened within
ASCEND:
    sys.setdlopenflags(dl.RTLD_GLOBAL|dl.RTLD_NOW)
import ascpy

(more details at
https://pse.cheme.cmu.edu/svn-view/ascend/code/branches/extfn/pygtk/gtkbrowser.py?rev=1475&view=markup
)

As you see, we're only using the dl module to give us the values of
some constants, before then going on and using the standard python
'import' command. We are *not* using the dl module to perform dlopen
calls. The values of these constants are, in general, platform
specific.

Why the length of various data types should preclude the 'dl' module
being available on AMD64, I'm not quite clear. I think that instead of
disabling 'dl' altogether in Python, the Debian build of Python 2.4
should *definitely* still make 'dl' available, but with with limited
functionality if there is a problem with getting some aspect to work.

Looks like my only option is to implement another non-standard module
that provides the RTLD_GLOBAL etc values and import than in place of
the 'dl' module. Now *that* is an ugly hack.

Cheers
JP



Reply to: