Re: [Distutils] Dynamic linking on Linux, Mac OS, et al
At 02:11 PM 1/6/2006 +0800, Jeff Pitman wrote:
Unless you do something really magical, you're going to find a lot of resistance to this in most Linux distro camps. Gentoo will want to recompile via emerge. Fedora/CentOS will want to grab from yum. Debian will want to grab libs via apt.
The issue for the PyICU/PyLucene etc. use cases is that there are a whole bunch of SWIG wrappers for different extensions, but with a large common library for type mapping etc. The authors want a shared library for *their own code* that is used by multiple extensions. This is not separately distributed code.
This is not the same thing as the Windows use case for building a shared library, although the ability to do it on Windows satisfies this use case too.
On Jan 6, 2006, at 8:19 AM, Phillip J. Eby wrote:
At 02:11 PM 1/6/2006 +0800, Jeff Pitman wrote:
Unless you do something really magical, you're going to find a lot of resistance to this in most Linux distro camps. Gentoo will want to recompile via emerge. Fedora/CentOS will want to grab from yum. Debian will want to grab libs via apt.
The issue for the PyICU/PyLucene etc. use cases is that there are a whole bunch of SWIG wrappers for different extensions, but with a large common library for type mapping etc. The authors want a shared library for *their own code* that is used by multiple extensions. This is not separately distributed code.
It'd be better if these projects just fixed themselves to do things the "right" way, using a Python extension and a function table.
-bob
On Jan 6, 2006, at 11:33 AM, Bob Ippolito wrote:
On Jan 6, 2006, at 8:19 AM, Phillip J. Eby wrote:
The issue for the PyICU/PyLucene etc. use cases is that there are a whole bunch of SWIG wrappers for different extensions, but with a large common library for type mapping etc. The authors want a shared library for *their own code* that is used by multiple extensions. This is not separately distributed code.
It'd be better if these projects just fixed themselves to do things the "right" way, using a Python extension and a function table.
Bob --
Can you explain to me in more detail what the "right" way is? I have a large number of swig wrapper files for a large number of C++ files. The program has a small number of core shared libraries that are always loaded, and a few that are optional. The shared library code is written in C++. Sometimes classes defined in the core libraries are used as base classes for classes defined in the optional libraries. All of this can be handled easily with shared libraries. How can it be done with function tables?
Thanks, Steve
-- -- EMail: stephen.langer@nist.gov Phone: (301) 975-5423 -- -- WWW: http://math.nist.gov/mcsd/Staff/SLanger/ Fax: (301) 990-4127 -- -- Mail: NIST; 100 Bureau Drive -- Stop 8910; Gaithersburg, Md 20899-8910 --
-- "I don't think this will work. That's why it's science." -- -- Naomi Langer, 17 Feb 2003 --
On Jan 6, 2006, at 6:55 PM, Stephen Langer wrote:
On Jan 6, 2006, at 11:33 AM, Bob Ippolito wrote:
On Jan 6, 2006, at 8:19 AM, Phillip J. Eby wrote:
The issue for the PyICU/PyLucene etc. use cases is that there are a whole bunch of SWIG wrappers for different extensions, but with a large common library for type mapping etc. The authors want a shared library for *their own code* that is used by multiple extensions. This is not separately distributed code.
It'd be better if these projects just fixed themselves to do things the "right" way, using a Python extension and a function table.
Can you explain to me in more detail what the "right" way is? I have a large number of swig wrapper files for a large number of C++ files. The program has a small number of core shared libraries that are always loaded, and a few that are optional. The shared library code is written in C++. Sometimes classes defined in the core libraries are used as base classes for classes defined in the optional libraries. All of this can be handled easily with shared libraries. How can it be done with function tables?
Numeric, Numarray, pygame, PyObjC, etc. are good references for how to export bits of C API as a function table. I don't use C++ unless I have to, so I'm not familiar enough with it to say whether or not it's going to cause problems given how you want to use it. Maybe it's not possible without refactoring the optional library code to work some other way.
-bob
On Jan 6, 2006, at 10:27 PM, Bob Ippolito wrote:
On Jan 6, 2006, at 6:55 PM, Stephen Langer wrote:
On Jan 6, 2006, at 11:33 AM, Bob Ippolito wrote:
On Jan 6, 2006, at 8:19 AM, Phillip J. Eby wrote:
The issue for the PyICU/PyLucene etc. use cases is that there are a whole bunch of SWIG wrappers for different extensions, but with a large common library for type mapping etc. The authors want a shared library for *their own code* that is used by multiple extensions. This is not separately distributed code.
It'd be better if these projects just fixed themselves to do things the "right" way, using a Python extension and a function table.
Can you explain to me in more detail what the "right" way is? I have a large number of swig wrapper files for a large number of C+
- files. The program has a small number of core shared libraries
that are always loaded, and a few that are optional. The shared library code is written in C++. Sometimes classes defined in the core libraries are used as base classes for classes defined in the optional libraries. All of this can be handled easily with shared libraries. How can it be done with function tables?
Numeric, Numarray, pygame, PyObjC, etc. are good references for how to export bits of C API as a function table. I don't use C++ unless I have to, so I'm not familiar enough with it to say whether or not it's going to cause problems given how you want to use it. Maybe it's not possible without refactoring the optional library code to work some other way.
Ok, I've looked at some of these examples. I haven't had the time to go through their mechanisms in detail, but it seems that under the hood they don't do anything terribly different from what swig does. I still don't see how they pertain to solving the shared library problem, and how doing things the "right" way makes shared libraries unnecessary.
If extension A and extension B both require routine Z, and there's no python extension for routine Z, isn't the best solution to put Z in a shared library?
I hope I'm not being dense here. We have lots of python extensions, all of which link to a relatively small number of shared libraries, and I'd like to understand why this setup is "wrong".
-- Steve
-- -- EMail: stephen.langer@nist.gov Phone: (301) 975-5423 -- -- WWW: http://math.nist.gov/mcsd/Staff/SLanger/ Fax: (301) 990-4127 -- -- Mail: NIST; 100 Bureau Drive -- Stop 8910; Gaithersburg, Md 20899-8910 --
-- "I don't think this will work. That's why it's science." -- -- Naomi Langer, 17 Feb 2003 --
participants (4)
-
Bob Ippolito -
Phillip J. Eby -
Stephen Langer -
Stephen Langer