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