This is a multi-part message in MIME format.
--------------891D4EE2BF7D211F1FE72A32
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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[2]: *** [libraptorhtml.so.1.0] Error 1
gmake[2]: Leaving directory `/mozilla/layout/build'
gmake[1]: *** [install] Error 2
gmake[1]: 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.

Steve

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:

> [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]

--------------891D4EE2BF7D211F1FE72A32
Content-Type: text/x-vcard; charset=us-ascii;
 name="scbrown.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Stephen Brown
Content-Disposition: attachment;
 filename="scbrown.vcf"

begin:vcard 
n:Brown;Stephen
tel;cell:(650)444-6750
tel;home:(408)278-1393
tel;work:(650)937-6689
x-mozilla-html:FALSE
org:Netscape Communications Corp.;Internal Computing
adr:;;501 E. Middlefield Rd.;Mountain View;CA;94043;USA
version:2.1
email;internet:Stephen_Brown@netscape.com
title:UNIX Systems Administrator
x-mozilla-cpt:;728
fn:Stephen Brown
end:vcard

--------------891D4EE2BF7D211F1FE72A32--