>  with LD_LIBRARY_PATH set to include both the mozilla dist/lib and my
>  python build's lib/, ldd says both libpyloader and _xpcom link to no
>  libpython at all!

Which would be correct if it had been linked against a static build of
Python - which is what I believe to be the root of the issue - both
libpyloader.so and _xpcom.so have their own, static version of Python linked
in, making sharing anything Python related between these 2 modules
impossible.

I don't know enough about the Linux build process, but it is the link
process that needs to locate the dynamic python, rather than simply have the
compile process enable dynamic linking for itself (ie, the issue is not how
pyxpcom is built, but how the Python you are linking against is built)

>  PYTHON_LIBS =
>  -L/var/brendano/trunk-build/external/release/lib/python2.4/config
>  -lpython2.4 -lutil

I don't think anything there is trying to insist on a dynamically built
Python - either way the link will work.  The underlying problem is that the
config process did not detect a non-dynamic Python and refuse to build.
Last I built this on Linux, I believe it did check.  Bug 129216 has a patch
from ShaneC which does mention supporting non-dynamic builds, but I haven't
looked into that.  Last I knew pyxpcom will simply not work with static
Python.

I may be mistaken - I guess ultimately you need to confirm if whatever is
being found by the '-lpython2.4' is a static or dynamic Python lib.

FWIW, a solution would appear to be rolling _xpcom and pyloader into the
same binary.  This would require a little import magic to make "import
_xpcom" magically use this single loader binary, but that is doable.
However, I'm not sure that is the way to move forward.  Let's say that in
the future there is a need for additional extension modules that depend on
other parts of the system (eg, JavaScript).  I think we want a module such
as this to use the core pyxpcom functionality without requiring it to be
rolled into the same binary (and thereby making the core pyxpcom binaries
suddenly depend on JS etc).  Python on Windows doesn't have this problem
simply as it has never even supported static builds, let alone allowing them
to be the default ;)

Mark

_______________________________________________
pyxpcom mailing list
pyxpcom@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs