SGI: Development

Well I've been trying to get a Firefox-2.0 built for Nekoware but have hit a snag I can't seem to find a solution for. I'm able to build the entire thing, but the very last link phase on the binary throws a spurious '-L' flag into the mix:



It's possible to manually link the above by correcting the '-L-L../../dist/bin' bit on the command line. Unfortunately this doesn't provide a solution since it'll just try to do it again once 'gmake -f client.mk build' is executed afterward.

The 'mozilla' build system is convoluted and about the only thing I can determine is that the bad link is part of the $(EXTRA_LIBS) variable in the link phase (line 809 of mozilla/rules.mk). $(EXTRA_LIBS) seems to get all sorts of things heaped into it from all over the place so I'm not able to isolate just where that one little bit is coming from.

As a point of reference, Firefox-1.5 series did not have this problem - the same bit is there but without the extra '-L':



I can't locate any differences that would account for it in the configuration files though.

This has been a problem throughout the Firefox-2.0 prerelease series, but now that it's 'gold' I'd like to see this running on IRIX. If anyone has any suggestions on how to get the build system over this hump we should be home free ...

I also filed a Bugzilla bug on this (#357780) to see if I can get some feedback on that end.

Can you grep for -L../../dist/bin in the Makefile.in or configure scripts and find the flag before it?

Okay, I found a nasty hack. Seems that the corrupt portion is part of NSS_LIBS which is embedded into STATIC_EXTRA_LIBS in config/static-config.mk. I just copied the whole '-L../../dist/bin -L../../dist/lib -lcrmf -lsmime3 -lssl3 -lnss3 -lsoftokn3' line and added it to STATIC_EXTRA_LIBS manually in the same file (killed the variable). We'll see how that goes

Okay - builds now, but just cores on startup.

nekonoko wrote: Okay - builds now, but just cores on startup.

Doh! I hate that.

Looks like foetz opened a bug; no further comments on it for a while though:

https://bugzilla.mozilla.org/show_bug.cgi?id=351261

I tried reverting https://bugzilla.mozilla.org/show_bug.cgi?id=347645 as mentioned but still get the crash in the same place.

Looks like Firefox-2.0 is DOA on IRIX unless someone with more skills than I can work this out.

At the risk of saying complete nonsense, there is a glitch between the MIPSpro compiler suite and other compilers in that it uses reverse order for macros that work twice on the same variable.

To check against this one could change the macro into a function and see whether that fixes the problem. For example (this is a Nasal/FlightGear example), changing:

#define PUSH(r) do { \
if(ctx->opTop >= MAX_STACK_DEPTH) ERR(ctx, "stack overflow"); \
ctx->opStack[ctx->opTop++] = r; \
} while(0);

into
# define PUSH(r) _PUSH((ctx), (r))
void _PUSH(struct Context* ctx, naRef r) {
if(ctx->opTop >= MAX_STACK_DEPTH) ERR(ctx, "stack overflow");
ctx->opStack[ctx->opTop++] = r;
}

causes the following code to start working:

PUSH(ctx->opStack[ctx->opTop-1]);

which ended up like:
ctx->opStack[ctx->opTop++] = ctx->opStack[ctx->opTop-1];

As you can see the ctx->opTop variable was accessed twice in the same macro. BTW. This macro is now rewritten like this:

// Note that opTop is incremented separately, to avoid situations
// where the "r" expression also references opTop. The SGI compiler
// is known to have issues with such code.
#define PUSH(r) do { \
if(ctx->opTop >= MAX_STACK_DEPTH) ERR(ctx, "stack overflow"); \
ctx->opStack[ctx->opTop] = r; \
ctx->opTop++; \
} while(0)

Erik

Could be the case, but I'll need to let a more experienced coder look into it - I'm an engineer by trade, not a programmer

nekonoko wrote: Looks like foetz opened a bug; no further comments on it for a while though:

https://bugzilla.mozilla.org/show_bug.cgi?id=351261

I tried reverting https://bugzilla.mozilla.org/show_bug.cgi?id=347645 as mentioned but still get the crash in the same place.

Looks like Firefox-2.0 is DOA on IRIX unless someone with more skills than I can work this out.

yeah sadly unlike a few years ago the mozilla guys don't seem very interested in non win/osx/linux stuff anymore

Line 71 of jsarena.c looks fishy to me in this regard:
JS_ARENA_ALIGN(pool, &pool->first + 1);

You might want to convert the JS_ARENA_ALIGN macro into a function to see if this solves the problem.

Erik

Not sure how to go about doing that (engineer, yadda yadda), but I can contribute a before/after of that code block (Firefox-1.5.0.7 and Firefox-2.0):

Firefox-1.5.0.7 jsarena.c:



Firefox-2.0 jsarena.c:

I think this would be the correct function for that:

jsuword JS_ARENA_ALIGN(JSArenaPool *pool, JSArena *n)
{
return (((jsuword)(n) + (pool)->mask) & ~(pool)->mask);
}

It would be nice to see the difference of the JS_ARENA_ALIGN macro between the two versions also.

You've lost me there, sorry.

Okay got this licked - new static MIPSpro Firefox-2.0 build in 'beta'. Hint was in bug #79562 - apparently they were maintaining a MIPSpro optimization exception list for certain files in the JS tree; jsxdrapi.o needs to be added to that list:

Neko, fantastic!

nekonoko wrote: Okay got this licked - new static MIPSpro Firefox-2.0 build in 'beta'.

Seems to run well, maybe a little faster ? Not sure. Only thing bad is that the rmb menu is now about six kilometers long and the "open in new tab" choice doesn't work [fireflop problem, not a nekoware problem.] To tell you the truth, I don't really like the way tabs work now. It's too easy to hit the "close" button when you mean to do something else.

One vote for 'move to /current,' tho. Gracias, nekonoko !

edit : the rmb button context menu returned to its previous behaviour, suddenly and all by itself. Not looking this gift horse in the mouth.