Subject: Re: mozilla maintainer wanted
To: Brad Spencer <email@example.com>
From: Stephen Brown <firstname.lastname@example.org>
Date: 04/25/2000 11:48:55
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
I seem to have gotten fairly far on the NetBSD/macppc side by creating
symlinks from "lib*.so" to the "lib*.so.1.0" everytime it stops like this
and then starting "gmake" again(kind of tedious though). I noticed
a variable in the configure script, "NEED_BASE_DLL_NAME_ALSO",
that seems to be supposed to address this, but it doesn't occur in any
of the Makefiles. Setting it seems to make no difference.
Anyway, my efforts seem to be stymied by lack of memory:
nsHTMLAttributes.o: could not read symbols: Memory exhausted
collect2: ld returned 1 exit status
gmake: *** [libraptorhtml.so.1.0] Error 1
gmake: Leaving directory `/mozilla/layout/build'
gmake: *** [install] Error 2
gmake: Leaving directory `/mozilla/layout'
gmake: *** [install] Error 2
This kind of seems odd, though as I have 64MB of real memory, of which top
claims 47MB are free. I also have plenty of free swap:
schizo# swapctl -l
Device 1K-blocks Used Avail Capacity Priority
/dev/sd1b 132462 0 132462 0% 0
This is on NetBSD 1.4X from the April 15 tar files.
p.s. I also wound up forcing the "NO_LD_ARCHIVE_FLAGS" variable
in configure as otherwise I wound up with "undefined reference" errors
on linking. Not sure what is up there.
Brad Spencer wrote:
> > 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
> 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]
Content-Type: text/x-vcard; charset=us-ascii;
Content-Description: Card for Stephen Brown
org:Netscape Communications Corp.;Internal Computing
adr:;;501 E. Middlefield Rd.;Mountain View;CA;94043;USA
title:UNIX Systems Administrator