SGI: Development

hamei wrote: Hate to splash cold water but if you are using the gtk2 that diegel recently built, pretty sure it is gcc. The release notes seemed to indicate that, anyhow.

That's correct current gtk2 and glib are both build with gcc 4.7. Possibly I will have the time to reproduce the netsurf build today.

Delighted to see this effort, having been using NS since its early RISC OS versions - but frustrated not to have relevant skills to assist (yet - but with the time available it's going to be a long haul up the learning curve!).

Yesterday evening I did try the "quick start" instructions (including env.sh) for the framebuffer version on an X86 machine - debian/jessie - and that fell over at one or two of the libraries so not plain sailing even in mainstream CPU/OS waters. Well, perhaps not quite a mainstream CPU these days - it's a VIA C3 lacking a 686 instruction, which may or may not be critical here.

diegel wrote:

hamei wrote: Hate to splash cold water but if you are using the gtk2 that diegel recently built, pretty sure it is gcc. The release notes seemed to indicate that, anyhow.

That's correct current gtk2 and glib are both build with gcc 4.7.

Thanks guys! I guess I should learn to read release notes, too. Anyway, your info prevents me from chasing down a false lead so hopefully that means I can spend more time looking for the actual problem.

If ShadeOfBlue is right and GCC code generation for MIPS is really finally fixed maybe it's time to drop MIPSPro from the nekoware tardist FAQ in favor of GCC 4.7+ (heresy heresy!).

There's still the problem that you can't mix C++ code generated by g++ and CC, since they use different name mangling algorithms.

vishnu wrote: If ShadeOfBlue is right and GCC code generation for MIPS is really finally fixed maybe it's time to drop MIPSPro from the nekoware tardist FAQ in favor of GCC 4.7+ (heresy heresy!).

This is GNU. It's only "finally fixed" until some random loser's commit breaks it for stupid and probably stupidly ideological reasons and then it remains broken for another year and a half until someone finally submits a patch that fixes it but breaks something else.

commodorejohn wrote: This is GNU. It's only "finally fixed" until some random loser's commit breaks it for stupid and probably stupidly ideological reasons and then it remains broken for another year and a half until someone finally submits a patch that fixes it but breaks something else.

quote of the month

jpstewart wrote: hopefully that means I can spend more time looking for the actual problem.

What's it do when you try to launch it, hanging or segfaulting? Because if it's hanging strace should show you where and if it's segfaulting the debugger should do likewise (provided you compiled it with -g passed to the compiler). Hmmmm, I just checked and neither strace or gdb are in nekoware! I'm sure Prodev Workshop has a tracer but I have extreme doubt about whether it will understand crap about gcc compiled code...

vishnu wrote: What's it do when you try to launch it, hanging or segfaulting? Because if it's hanging strace should show you where and if it's segfaulting the debugger should do likewise (provided you compiled it with -g passed to the compiler).

It's hanging, quite a ways into the initialization process. Running netsurf with it's '-v' option logs a lot of helpful messages to the terminal. Even without '-v' GTK/GLib are dumping some harmless warnings and a couple of "critical" errors to the terminal, but much earlier than the hang. From running 'netsurf -v':

And much later it hangs with these:

However my current hypothesis is that those earlier GTK/GLib messages are the root cause. I think it's failing to properly setup the tabs and then later hanging when trying to access that tab. I've tracked that problem to what appears to be a bad pointer in netsurf/gtk/tabs.c, line 162 where NetSurf's nsgtk_tab_switch_page_after callback function calls into GLib's g_object_get_data. Whether or not that's the actual cause of the problem remains to be seen. But there's definitely something wrong with the pointers going around there, and that's today's working theory. (But I've had a lot of other false leads. )

vishnu wrote: Hmmmm, I just checked and neither strace or gdb are in nekoware! I'm sure Prodev Workshop has a tracer but I have extreme doubt about whether it will understand crap about gcc compiled code.

Well, there are ancient versions of both strace and gdb in SGI's freeware if I get really desperate. (There's also /usr/sbin/strace but that's not the same strace!) Prodev Workshop has been on my "must learn" list for a while, but so far I have zero experience with it.

But the real problem is that I tend to get frustrated and angry when debugging other people's code. Screaming "why doesn't it work?" isn't exactly the best debugging process, but one that I employ a lot. That, and the fact that I can only work on it during evenings and weekends are slowing things down a bit.

BTW, for anyone interested: I did manage to remove the GCC-specific flags from the Makefiles and compile NetSurf with MIPSpro. That one fails even earlier in the launch process (no window ever appears, it just prints an error message and exits). Oh well.

The Prodev debugger is awesome, and so much prettier than the eyesore that is xxgdb. Then again for gdb there's always ddd which looks pretty dang fancy as well...

jpstewart wrote: compile NetSurf with MIPSpro. That one fails even earlier in the launch process (no window ever appears, it just prints an error message and exits)

i remember that it's been mentioned that some libs required by netsurf were compiled with g++?
if so that's a likely reason

i remember that it's been mentioned that some libs required by netsurf were compiled with g++?
if so that's a likely reason

If that were the case, it would already fail when linking, and not produce an executable at all.

canavan wrote:

i remember that it's been mentioned that some libs required by netsurf were compiled with g++?
if so that's a likely reason

If that were the case, it would already fail when linking, and not produce an executable at all.

sure, assuming that nothing has been "updated" after

Resurrecting this a bit. Would be nice to have a working NetSurf 3.5 with JS enabled on IRIX.
Never having tried to build anything on IRIX, I don't think im the right person to try to make it work.

All I can do is encurage someone to do it. So come on, someone try building it!

NetSurf is speedy and works terribly well for what it is on my Atari Falcon 060 running FreeMiNT, would be wonderful to have it running on IRIX.

ISTR having endian trouble getting it working on OS X/ppc (10.4, anyway). That was 3.0, however, so maybe it's fixed.

Any progress made on this? Like some others here, I don't really have the knowledge required to make it work, but if anyone else has made progress I would love to know.