nope, that's correct, my email was sloppy about what the config
options exactly were :)  Yeah, I saw that patch, but my problem is in
the OPPOSITE direction of the problem the patch was supposed to fix,
so I don't think it's relevant... hopefully...

On 8/10/05, Stefan Farestam <stefan@[...].net>  wrote:
>  
>  There is one more "--enable-unicode" which can either be set
>  to "ucs2" or "ucs4", i.e. one of:
>  
>     --enable-unicode=ucs4
>     --enable-unicode=ucs2
>  
>  It used to be that you needed to compile with ucs2, but I think
>  the latest patch make it build on ucs4, which I believe is the
>  default build and the one used by most distributions.
>  
>  Someone, please correct me if any of the above is incorrect.
>  
>  
>  Brendan O'Connor wrote the following on 08/10/2005 12:08 AM:
>  > --enable-shared builds python dynamically, right?  There shouldn't be
>  > any other python config issues?  If I can eliminate that then at least
>  > the range of problems have been narrowed to mozilla build issues.
>  >
>  >
>  > On 8/9/05, Mark Hammond <mhammond@[...].au> wrote:
>  >
>  >>>Anyway, I stepped through it up to the point where the segfault
>  >>>happens.  There are no null pointers or anything like nice/simple like
>  >>>that.  Rather, the segfault happens when trying to load _xpcom (the
>  >>>python extension module).  Inside PYXPCOM_GlobalsEnsure(), it tries to
>  >>>PyImport_ImportModule("xpcom").  (src/xpcom.cpp:509)  During the
>  >>>python interpreter's process of importing a module, at some point it
>  >>>needs to get the current frame, calling this function
>  >>>(Python-2.4.1/Python/ceval.c:338):
>  >>
>  >>Is it possible that your Python is not built dynamically?  With a statically
>  >>linked Python, you may end up with 2 instances of Python loaded into the
>  >>process which will cause very similar problems.  Can gdb tell you the .so
>  >>files which have been loaded?  If so, do any appear twice (or the same base
>  >>name from different dirs?)
>  >>
>  >>Re your other points: 1 & 2 should be fine, and I agree 3 is unlikely to be
>  >>related - unless something related to resolving the Unicode functions in
>  >>Python actually is somehow causing multiple Pythons to be loaded.
>  >>
>  >>Mark
>  >>
>  >>
>  >
>  >
>  > _______________________________________________
>  > pyxpcom mailing list
>  > pyxpcom@[...].com
>  > To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
>  >
> 

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