[Distutils] SWIG runtime libs/Python distutils combo on Mac
bob at redivi.com
Wed Sep 29 23:27:35 CEST 2004
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",
>>>>> 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
>>>> 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.
More information about the Distutils-SIG