Assuming login.conf is already set appropriately and it's a new login session, the maximum ulimit is limited by MAXDSIZ which is set in /sys/arch/mips64/include/vmparam.h.
Brian Callahan <bcal...@devio.us> wrote: > > >On Thu, 25 Oct 2012, Landry Breuil wrote: > >> On Thu, Oct 25, 2012 at 12:01:47PM -0400, Brian Callahan wrote: >>> Hi ports -- >>> >>> I got devel/spidermonkey working on one of my loongson machines. >>> Builds/installs OK and 'make regress' passes all tests. That's as >>> far as I've gotten testing-wise. >> >> wow, that is awesome ! Now, i dont agree with some parts of the patch >> that mix stuff for mips*/mips64 with things that might be mips64el >only >> - maybe a little variation of this would allow spidermonkey to build >on >> 'regular' mips64. >> >> Can you try building www/fennec then firefox with that patch applied >to >> js/src ? >> > >I already know that firefox won't build because libxul fails at linking > >(memory exhausted). There are 2 "solutions" I can think of off-hand: >get >clang working and pray it uses less memory (probably ideal, since gcc >4.2 >is being deprecated for firefox, no?) or get the ulimit bumped up to 2 >GB. >My Fuloong has 2 GB RAM (and the kernel recognizes it all) so I'd be >willing to test experimental patches in order to get the ulimit -d as >close to 2 GB as possible. > >Does www/fennec also build libxul? > >> Landry >> >>> ++# XXX: Fix for mips64el >>> ++ifeq (mips, $(CPU_ARCH)) >>> ++CXXFLAGS += -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=0 >-DENABLE_JIT=0 >>> ++else >>> + CXXFLAGS += -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1 >-DENABLE_JIT=1 >>> ++endif >> >> Oh, the horror. I've been there, and it's an atrocious define hell. >> that wont be acceptable upstream, see >> https://bugzilla.mozilla.org/show_bug.cgi?id=691898 for the hell it's >> been with ppc. >> > >My thought process here was that there is nothing in the spidermonkey >sources for a MIPS assembler (possibly the JIT as well). If this line >isn't included then while building you get tons of -DENABLE_ASSEMBLER >and -DENABLE_JIT redefined warnings. It says the original define comes >from stdin, and then uses -DENABLE_ASSEMBLER=1 and -DENABLE_JIT=1 which > >causes the build to fail since it tries to build an assembler that >doesn't >exist. > >>> + ++/* CPU(MIPS64) - MIPS64 (Loongson only!) */ >>> ++#if defined(__mips64__) >> >> mips64el here ? >> > >How about this, borrowing from webkit: >#if defined(__mips64__) >#if defined(__MIPSEB__) >#define BIG_ENDIAN 1 // or whatever the switch for big endian machines >is >#endif >#define WTF_CPU_MIPS64 1 >... > >This way we can catch mips64el and regular mips64. > >>> + +-mips|mipsel) >>> ++mips*) >>> + CPU_ARCH="mips" >> >> I'd rather have a new section adding mips64|mips64el.. >> or add them to the same section? that part should be taken upstream. >> See the section setting ENABLE_METHODJIT in configure.in, i've been >> told to add if test ! "$HAVE_64BIT_OS" ; then to set those bits >only >> on sparcv8 and not sparcv9 - same thing might be needed for mips64. >> > >Sounds reasonable. I'll take a look when I get home. > >>> +@@ -2515,7 +2515,7 @@ ia64*-hpux*) >>> + alpha-*) >>> + AC_DEFINE(_ALPHA_) >>> + ;; >>> +- mips-*) >>> ++ mips*-*) >>> + AC_DEFINE(_MIPS_) >> >> Ditto here, that should be upstreamable. Can you file a bug on >> bugzilla.mozilla.org with all your findings and cc me on it ? >> > >Should we do this in a new mips64|mips64el section as well? And should >it >be then AC_DEFINE(_MIPS64_) or is AC_DEFINE(_MIPS_) ok here? > >Like above, I'll take a look at this when I get home and file upstream. > >> Landry >> >> > >Thanks. > >~Brian
