Subject: Re: mozilla maintainer wanted
To: None <email@example.com>
From: Brad Spencer <firstname.lastname@example.org>
Date: 04/25/2000 13:36:33
> The problem seems to be in
> 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
pos# ldd 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
> 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 - email@example.com http://anduin.eldar.org
[finger firstname.lastname@example.org for PGP public key]