Subject: Re: mozilla maintainer wanted
To: None <current-users@netbsd.org, port-macppc@netbsd.org>
From: Stephen Brown <scbrown@netscape.com>
List: current-users
Date: 04/26/2000 12:50:11
Hmm,

I managed to get mozilla M15 built, but am having problems running it now:

% run-mozilla.sh
MOZILLA_FIVE_HOME=/mozilla/dist/bin
  LD_LIBRARY_PATH=/mozilla/dist/bin:/u/scbrown/lib:/usr/openwin/lib
       SHLIB_PATH=/mozilla/dist/bin
          LIBPATH=/mozilla/dist/bin
      MOZ_PROGRAM=viewer
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
/mozilla/dist/bin/libgtksuperwin.so: Unsupported relocation type 10in non-PLT
relocations

I am guessing that this may be something specific to the "macppc" port, as
I haven't
seen it discussed by anyone else.  If somebody with more of a clue knows why
I'm getting this, please let me know if I need some different compilation flags or
if
the tool-chain on "macppc" is slightly broken and needs fixing, etc.

Thanks,
Steve


Stephen Brown wrote:

> Duh! It was the per-user limits.  Now I feel stupid.  But, the build is
> churning away again.  I'm not sure if the numbers from "top" are
> accurate(it was built under an earlier version of current, etc). but
> assuming they are, the "ld" process gets huge in a mozilla build:
>
> load averages:  1.66,  1.76,  1.22                                      12:37:16
>
> 34 processes:  2 running, 32 sleeping
> CPU states:  2.5% user,  0.0% nice,  3.0% system,  0.0% interrupt, 94.5% idle
> Memory: 35M Act, 17M Inact, 228K Wired, 860K Free, 24M Swap, 106M Swap free
>
>   PID USERNAME PRI NICE   SIZE   RES STATE   TIME   WCPU    CPU COMMAND
> 12787 root      -6    0    71M  323M sleep   1:23  9.08%  9.08% ld
>
> I'll let everyone know if the beast actually works once it finally finishes
> building...
>
> Steve
>
> Brad Spencer wrote:
>
> >    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.
> >
> > I'v never seen anything like the above on NetBSD/i386 when trying to do
> > the builds.  What is the user process limits on the user that is
> > attempting to build Mozilla???
> >
> > Brad Spencer - brad@anduin.eldar.org   http://anduin.eldar.org
> > [finger brad@anduin.eldar.org for PGP public key]