Geoffrey Furnish <furnish@actel.com> writes: [...]

This case is different. you aren't building a shared lib, and your link line doesn't link your extension module against any shared libs. Instead, you are expecting to pick up your missing external symbols by having them bound against the symbols in the enclsoing process context. i.e., Python itself.

I find the situation here a little weird too, but I'm trying to follow the "supported Python way" by using the Setup file and Makefile.pre.in, which apparently advocates this system.

In order for this to work, some systems (I don't know whether Slowaris is like this or not, but some are, so it might be) require that the host application must "export symbols" so that the dynamic loader can consider them candidates for symbol resolution when dso's are dynloaded.

In other words: link your Python with "-Wl,-E" (but it doesn't have to be compiled -fPIC) Compile your extension module with -fPIC, lijnke with -shared.

It seems you're now doing this last step, but I don't think we've seen from the info presented earlier if you're doing the first step.

Maybe you didn't catch the end of my first post. I did build my Python with the '-Wl,-E', but I never saw those options actually get used in the build. I pushed the options into my LDSHARED environment variable before running configure. I can tell that those options did get captured in the Makefile. It seems that by default the Python build doesn't create any shared objects, so maybe that's why my LDSHARED options never came into play. Should I be trying to get the '-Wl,-E' option crammed into some other build-time variable? I'm sorry, but I'm not sure I understand which parts of the system will wind up caring about those options. -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com