[C++-SIG] Re: C++ extension module crashes on Solaris

[Steve Harris]

Geoffrey Furnish <furnish at 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