[Python-Dev] Static linking with libpython.a
Hello, I am trying to figure out, what files to copy with my app so I am able to initialize the python runtime. Where can I find information about this? I am currently targeting Mac OS X 10.5 and above. Thank you, Filip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] debug and release python
Hello there. I'm sure this has come up before, but here it is again: Python exports a different api in debug mode, depending on whether PYMALLOC_DEBUG and WITH_PYMALLOC are exported. This means that _d.pyd files that are used must have been compiled with a version of python using the same settings for these macros. It is unfortunate that the _PyObject_DebugMalloc() api is exposed to external applications using macros in objimpl.h I would suggest two things: 1) provide dummy or thunking versions of those in builds that don't have PYMALLOC_DEBUG impolemented, that thunk to PyObject_Malloc et al. (This is what we have done at CCP) 2) Remove the _PyObject_DebugMalloc() from the api. It really should be an implementation of in the exposed PyObject_Malloc() functions whether they use debug functionality at all. the _PyObject_DebugCheckAddress and _PyObject_DebugDumpAddress() can be left in place. But exposing this functionality in macros that external moduled compile in, is not good at all. The reason why this is annoying: Some external software comes with proprietary .pyd bindings. When developing my own application, with modified preprocessor definitions (e.g. to turn off PYMALLOC_DEBUG) we find that those externally provided libraries don't work. It takes a fair amount of detective work to find out why exactly linkage fails. The external API really shouldn't change depending on preprocessor definitions. Cheers, K ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] debug and release python
Some external software comes with proprietary .pyd bindings. Can you please explain what a "proprietary .pyd binding" is? Do you mean they come with extension modules? If so, there is no chance of using them in debug mode, anyway, right? So what specifically is the problem? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Sharing functions between C extension modules in stdlib
I have learned a long time ago that it is not enough to simply declare a function in some header file if you want to define it in one module and use in another. You have to use what now is known as PyCapsule - an array of pointers to C functions wrapped in a Python object. However, while navigating through the time/datetime maze recently I have come across timefuncs.h which seems to share _PyTime_DoubleToTimet between time and datetime modules. I did not expect this to work, but apparently the build machinery somehow knows how to place _PyTime_DoubleToTimet code in both time.so and datetime.so: $ nm build/lib.macosx-10.4-x86_64-3.2-pydebug/datetime.so | grep _PyTime_DoubleToTimet f4e2 T __PyTime_DoubleToTimet $ nm build/lib.macosx-10.4-x86_64-3.2-pydebug/time.so | grep _PyTime_DoubleToTimet 0996 T __PyTime_DoubleToTimet I have two questions: 1) how does this happen; and 2) is this intentional? Thanks. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing functions between C extension modules in stdlib
On Mon, Jun 14, 2010 at 6:45 PM, Alexander Belopolsky
wrote:
..
> I did not expect this to work, but apparently the build machinery
> somehow knows how to place _PyTime_DoubleToTimet code in both time.so
> and datetime.so:
..
> I have two questions: 1) how does this happen; and 2) is this intentional?
>
OK, the answer to the first question is simple: in setup.py, we have
exts.append( Extension('datetime', ['datetimemodule.c', 'timemodule.c'],
libraries=math_libs) )
but if timemodule.c is compiled-in with datetime module, why is does
it also need to be imported to share some other code?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing functions between C extension modules in stdlib
$ nm build/lib.macosx-10.4-x86_64-3.2-pydebug/datetime.so | grep
_PyTime_DoubleToTimet
f4e2 T __PyTime_DoubleToTimet
$ nm build/lib.macosx-10.4-x86_64-3.2-pydebug/time.so | grep
_PyTime_DoubleToTimet
0996 T __PyTime_DoubleToTimet
I have two questions: 1) how does this happen;
'T' means "defined in text segment", so it looks like the code is
included twice. And indeed, it is:
exts.append( Extension('time', ['timemodule.c'],
libraries=math_libs) )
exts.append( Extension('datetime', ['datetimemodule.c', 'timemodule.c'],
libraries=math_libs) )
> and 2) is this intentional?
This was added with
r36221 | bcannon | 2004-06-24 03:38:47 +0200 (Do, 24. Jun 2004) | 3 Zeilen
Add compilation of timemodule.c with datetimemodule.c to get
__PyTime_DoubleToTimet().
So it's clearly intentional. I doubt its desirable, though. If only
__PyTime_DoubleToTimet needs to be duplicated, I'd rather put that
function into a separate C file that gets included twice, instead of
including the full timemodule.c into datetimemodule.c.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Static linking with libpython.a
On Mon, Jun 14, 2010 at 6:29 AM, F van der Meeren wrote: .. > I am trying to figure out, what files to copy with my app so I am able to > initialize the python runtime. > Where can I find information about this? On comp.lang.python forum. This forum is for developing python itself, not applications using python. However, in general, you need code in Python, Parser, and Objects directories. See LIBRARY_OBJS definition in the Makefile. These days you also need some bootstrap code from Lib, AFAIK. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
