distutils problem with interdependent modules

[Daniel Wexler]

"Martin von Loewis" <loewis at informatik.hu-berlin.de> wrote in message
news:j4vgf0cicv.fsf at informatik.hu-berlin.de...
> "Daniel Wexler" <wex at flarg.com> writes:
>
> > C1, C2  - two pure C libraries (i.e.. not Python extensions)
> > P1, P2 - two C extension modules
> >
> > C2 requires functions in C1
> > P1 requires functions in C2
> > P2 requires functions in P1 and C1
>
> Please don't do that. On Unix, P2 cannot see any symbols from
> P1. Never mis-use an extension module as a shared library.

Perhaps I don't understand you clearly.  This system does work
just fine under Linux and Windows.  Under Linux the linker
can export all non-static symbols.  Under Windows, yes, you
do need to explicitly export symbols using one of three methods,
but it also works just fine.

I can understand a philosophical argument that you shouldn't
use an extension as a shared library, but the truth is that it is
a shared library, and I don't see why I can't use it as one.  It
works just fine.

Perhaps you are suggesting that I separate out the Python glue
code that is used to make what is normally just a C shared library
into a Python C extension module?  I could do that easily, but
that would just result in two DSOs, one for my C shared lib
and another for the Python C extension.  I can see how that would
solve the problem I posted, but the solution is cumbersome.
Personally, I'd rather just rename the python C extensions as
libfoo.so rather than split them up just for distutils.


Dan