ah, thanks for the info.  to clarify, i meant that i did
--enable-shared for the *python* build, and found that it had made and
installed libpython2.4*.so, and i thought i symlinked them into
lib/python2.4/config correctly -- that's why i thought i had done
everything correctly on the python side.  basically, i tried to
imitate the way the fc4 rpm was built.  maybe i'll double check it all
tomorrow, then...

brendan

On 8/10/05, Mark Hammond <mhammond@[...].au>  wrote:
>  > 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