Ok. Problem solved.

I grabbed the latest nightly-build tar bundle from mozilla and
recompiled everything and now it works! unfortunately I have
no clue what caused the problem that I previously reported. It
might just have been a bad intermediate tar-bundle of mozilla.

One other thing that I changed: instead of using the directory
created by doing "make install", I used the "mozilla/dist/bin"
directory that is built from the initial make.

So, case closed.

Mark Hammond wrote the following on 08/16/2005 11:40 PM:
> >Ok. In my case nspr4.dll is located in the mozilla library directory.
> >The "components" directory, with xpti.dat and compreg.dat, is a
> >subdirectory
> >of the the mozilla library directory.
>  
>  
>  That sounds correct so should work.
>  
>  
> >Are you saying that I need to hack the source code for pyxpcom to do this?
> >If so where?
>  
>  
>  The code I was referring to is in xpcom.cpp, line 529.  The block:
>  
>  			// On Windows this by using locating a Moz DLL we depend
>  			// on, and assume it lives in that bin dir.  Different
>  			// moz build types (eg, xulrunner, suite) package
>  			// XPCOM itself differently - but all appear to offer
>  			// nspr4.dll - so this is what we use.
>  			char landmark[MAX_PATH+1];
>  			HMODULE hmod = GetModuleHandle("nspr4.dll");
>  			if (hmod==NULL) {
>  				PyErr_SetString(PyExc_RuntimeError, "We dont appear to be linked against
>  nspr4.dll");
>  				return PR_FALSE;
>  			}
>  			GetModuleFileName(hmod, landmark, sizeof(landmark)/sizeof(landmark[0]));
>  
>  is attempting to locate the xpcom directory - which I believe should be the
>  directory with compreg.dat.  From what you described, I think you would find
>  that the directory portion of 'landmark' does point to the correct
>  directory.
>  
>  
> >Would be nice to avoid hardcoding since I would like to be able to
> >move around the install between machines without recompiling.
>  
>  
>  Yes, hence I said we need to find a better way :)
>  
>  
> >What mystifies me is that I haven't really changed much from the build
> >procedure that I used 8 months ago, but now the behavior is different.
>  
>  
>  I was guessing it was Mozilla itself that has moved on.  It sounds like I
>  may be wrong in this case.  I seem to have successful builds for both the
>  'xul_runner' and 'suite' projects.
>  
>  
> >By the way, my work-around is to remove compreg.dat and start mozilla
> >which then performs an auto-registration of components.
>  
>  
>  So once you have done that, stand-alone Python programs using xpcom again
>  work?  Bizarre...
>  
>  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