[snip]

   > The problem seems to be in
   > 
   >   xpcom/tools/registry
   > 
   > Trying to link gives "Cannot open -lxpcom: No such file or directory"

   I was looking into this on the -i386 side. The problem here is 
   that with shared libraries the linker is looking for 
   libxpcom.so. mozilla installs a link in dist/bin and dist/lib 
   for libxpcom.so.1.0. Making a link from libxpcom.so.1.0 to 
   libxpcom.so kept things compiling.

   Except that even doing you still can't run the regExport binary 
   since:
   pos# ldd regExport 
   regExport:
	    -lplds4 => not found
	    -lplc4 => not found
	    -lnspr4 => not found
	    -lxpcom.1 => not found

The above occures on all Mozilla programs.  They pretty much presume that
the LD_LIBRARY_PATH is set to the "home" location of mozilla-bin.  If you
look at the 'mozilla' shell script you will notice that it does this.
Everything appears to indicate that you can not run the Mozilla binaries
directly.

   > This was with static libraries enabled.  Without statics, it whinges
   > about (from memory, an error something like) 'mixed relocation types'
   > when linking...

[someone else mentioned]

Ya, for me [1.4P/i386/a.out], this was caused by linking into the shared
Mozilla libraries a static libintl from /usr/lib.  One way to deal with
this is to build a shared version of libintl from the packages collection
manually and installing it.

I am planning on posting some stuff later today on what I have found so
far in terms of getting things to build and the segfault that happens when
trying to run the browser.


Brad Spencer - brad@anduin.eldar.org   http://anduin.eldar.org
[finger brad@anduin.eldar.org for PGP public key]