[Distutils] SWIG runtime libs/Python distutils combo on Mac

[Bob Ippolito]

On Sep 29, 2004, at 5:10 PM, Bill Spotz wrote:

>
> On Sep 29, 2004, at 2:57 PM, Bob Ippolito wrote:
>
>> On Sep 29, 2004, at 4:43 PM, Bill Spotz wrote:
>>
>>> On Sep 27, 2004, at 10:19 AM, Bob Ippolito wrote:
>>>
>>>> On Sep 27, 2004, at 12:03 PM, Bill Spotz wrote:
>>>>
>>>>> To get around the portability problem, I have decided to use 
>>>>> python's distutils module to handle the compilation issues.  In my 
>>>>> setup.py script, I define
>>>>>
>>>>>   SwigRun = Extension("PyTrilinos.libswigrun", 
>>>>> ["src/swigrun_wrap.c"])
>>>>>
>>>>> and this works, as build/lib.blahblahblah/PyTrilinos/libswigrun.so 
>>>>> gets created properly.  When I define real extensions in setup.py, 
>>>>> they are created with keyword arguments
>>>>>
>>>>>     library_dirs    = [..., "build/lib.blahblahblah/PyTrilinos", 
>>>>> ...],
>>>>>     libraries       = [..., "swigrun", ...],
>>>>>
>>>>> which gives me the link command arguments I want: 
>>>>> -Lbuild/lib.blahblahblah/PyTrilinons -lswigrun.  However, on my 
>>>>> Mac, when the link command is invoked, I get
>>>>>
>>>>>     ld: can't locate file for: -lswigrun
>>>>>
>>>>> I strongly suspect that the Mac's ld command does not search for 
>>>>> libswigrun.so when -lswigrun is given as a command line argument 
>>>>> (the old system libraries have .la and .dylib extensions).  But I 
>>>>> cannot figure out how to get setup.py to compile to a different 
>>>>> suffix.
>>>>
>>>> You can't do this on OS X.  You can link to two types of files in 
>>>> OS X, static libraries and dylibs.  Python extension modules are 
>>>> bundles (runtime loadable code) and can not be linked to at compile 
>>>> time.  You should either compile swigrun_wrap into every extension, 
>>>> or make it a static library (which is more or less the same thing).
>>> I'm pretty sure I cannot compile swigrun_wrap into every extension 
>>> or make it a static library, since each extension will get its own 
>>> copy and that will defeat the purpose of the runtime libraries.  
>>> Sounds like I need to create a dylib, that python distutils can't 
>>> help me, and that I'll have to learn libtool if I want to make it 
>>> portable.  Does that sound about right?
>>
>> I don't think your assessment of swigrun_wrap is correct.
>
> I base my assessment on a couple of passages from the SWIG manual:
>
>> (15.1) By default, the runtime functions are private to each 
>> SWIG-generated module. That is, the runtime functions are declared 
>> with "static" linkage and are visible only to the wrapper functions 
>> defined in that module. If two completely different SWIG modules are 
>> loaded, this presents no problem---each module uses its own private 
>> runtime code. The only problem with this approach is that when more 
>> than one SWIG module is used in the same application, those modules 
>> often need to share type information. This is especially true for C++ 
>> programs where SWIG must collect and share information about 
>> inheritance relationships that cross module boundaries.

I'm not really sure this applies, try it and see what happens.

>> (15.3) When working with multiple SWIG modules, you should take care 
>> not to use static libraries. For example, if you have a static 
>> library libfoo.a and you link a collection of SWIG modules with that 
>> library, each module will get its own private copy of the library 
>> code inserted into it. This is very often NOT what you want and it 
>> can lead to unexpected or bizarre program behavior. When working with 
>> dynamically loadable modules, you should try to work exclusively with 
>> shared libaries.
>
> I am definitely trying to create multiple modules that need to share 
> type information for inheritance purposes.

It sure sounds as if they're talking about the library you're wrapping, 
not swigrun, in this paragraph.

-bob