[Distutils] Dynamic linking on Linux, Mac OS, et al

[Stephen Langer]

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 at 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         --