The collected works of jpstewart - Page 4

And another update for anyone still following along: NetSurf 3.1 builds with GCC on IRIX once you tweak a few defines in the Makefiles and set up your environment (especially PKG_CONFIG_PATH) correctly. Note that I said "builds". Not "runs".

If anyone wants to try debugging it, let me know and I'll post instructions and a patch for building it yourself. Otherwise, I'll try to debug it myself over the course of the coming week (although I'll probably only be able to work on it in the evenings).

Today was a holiday around here, and I'd been wanting an excuse to spend some quality time with my Octane. This project fit the bill quite nicely!

I think that the neko_librsvg-2.18.2 package is missing a dependancy on neko_gnomevfs. It's not listed as one of the required packages, but the actual /usr/nekoware/lib/librsvg-2.so file is linked to the /usr/nekoware/lib/libgnomevfs-2.so.1 library according to ldd. And (AFAICT) it won't work without gnomevfs installed.

Can anyone confirm that problem, or am I mis-reading something?

You will need all of the following libraries installed:

• neko_gtk+-2.12.12
• neko_curl-7.19.7
• neko_libpng-1.2.47
• neko_libjpg-1.2.1
• neko_librsvg-2.18.2
• neko_libiconv-1.14

(See also my note about librsvg if you have trouble with it.)

You will need the following utilities to get through the build process:

• neko_make-3.82
• neko_pkgconfig-0.23
• neko_fileutils-4.1
• neko_gperf-3.0.4
• neko_perl-5.8.9
• neko_perl_html_parser-3.55
• neko_expat-2.1.0
• neko_tar-1.26

You'll also need GCC. I used a self-compiled GCC, but neko_gcc47-4.7.1 should also work.

Make sure that /usr/nekoware/bin is first in your path. You'll need install (from neko_fileutils), perl, and tar from Nekoware to come before the standard IRIX ones which won't work with the NetSurf build system.

Download and extract the netsurf-all-3.1.tar.gz source code. In the resulting netsurf-all-3.1 directory, do as recommended by the NetSurf docs (assuming you extracted it into ${HOME} -- adjust to suit your own path):

Note the two colons at the end of PKG_CONFIG_PATH. That's not a typo.

Then to build with GCC:


Apply the attached patch (with "patch -p1 <../netsurf-irix.patch" from within the netsurf-all-3.1 directory). It mainly changes "-std=c99" to "-std=gnu99" in the options passed to GCC. (The IRIX headers disable all extensions in ANSI c99 mode but enable them in gnu99 mode.) The patch also adds a couple of missing includes in places, creates two configuration files, and makes one small change to work with the GTK version in Nekoware. (Note that NetSurf says it works with GTK 2.12+ but some features seem to be from 2.16 and 2.18. They produce warnings when I try to start up NetSurf.)

Then for each of the following subdirectories (in order), "cd" into it and run "gmake install". (I've ignored the top-level Makefile for now.)

• buildsystem
• libparseutils
• libwapcaplet
• libhubub
• libcss
• libnsgif
• libnsbmp
• librosprite
• libdom
• netsurf

You should have a netsurf binary in ${PREFIX}/bin. Check with ldd to make sure it's linked against the right Nekoware libraries. (NetSurf's own libraries were statically linked if you followed my process.) Try running it with "./netsurf -v" (assuming you're in ${PREFIX}/bin). On my system the NetSurf window opens and in the console there are a whole lot of harmless-looking Gtk-WARNING messages, a couple of GLib-GObject messages that worry me, and NetSurf's own very detailed log messages stop after it logs calling "gtk/window.c gui_window_set_icon". Then it just sits there eating 100% CPU.

That's as far as i got over the weekend. Thanks, diegel, for offering to help debug this. If anyone else wants to pitch in, I hope the above instructions are sufficiently detailed. And if we get it built and working with GCC, I'll look into buiding it with MIPS Pro.

And here's the patch that I forgot to attach to the previous post. Oops!

And yet another thing I forgot to mention earlier (and that should have been included in the patch ): watch out for '%zu' in printf statements, especially the LOG macro. IRIX printf doesn't like the z. Running NetSurf in verbose mode (i.e., with the '-v' option) will spew binary garbage. Change '%zu' to simply '%u' instead, before compiling it. The occurence in netsurf/image/png.c, line 181 in particular caused me problems. It's used a few other places, too, and they should all be removed.

foetz wrote: niice work jpstewart but being gtk2 based and coming with gcc specials do you think that it's a big difference compared to firefox?
don't get me wrong it's great to see any sort of irix effort however i wonder if that effort wouldn't be better spent on dillo

Frankly, I have no idea. My involvement here is basically just a quirk of timing. I saw TeamBlackFox's post on the Saturday morning of a long weekend and thought to myself, "that sounds like something fun to work on this weekend". That was pretty much the entirety of my thought process. I certainly never considered any of the questions you're asking and I personally am probably not in a position to answer them even if I had thought about them!

Once I got into the build process, I discovered that the Makefiles add lots of GCC options to the command line, so I figured I'd try building with GCC as first step to ease the porting process. (I.e., first worry about operating system portability issues, then worry about compiler portability problems.) But now that I've built it with GCC and it's not working, I'm not so sure that was good idea. I (re-)discovered this in the IRIX c99 manpage today:

cc(1) wrote: The gcc compiler does not correctly pass/return structures that are smaller than 16 bytes and which are not 8 bytes. gcc is consistent with itself, but not consistent with the MIPSpro C compiler, so the only failures that can happen are when mixing code compiled with the two compilers.

That same issue is also mentioned (although not specifically about SGI) in the "Incompatibilites" section of the GCC documentation, too. NetSurf passes a lot of structs back and forth with GTK. I can't help but wonder if that's (part of) the problem with my GCC build. AFAIK, the neko_gtk package was compiled with MIPSpro.

I'm hoping to get a chance to try again to build with MIPSpro this coming weekend. Unless, of course, somebody else gets its working first.

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.

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.

Thanks for looking into it, canavan. Glad to know I'm not the only one.

When I looked at the output of ldd, I assumed things like libbonobo and libORBit were only needed by gnomevfs. I see readelf says otherwise!

guardian452 wrote:

Trippynet wrote: That's pretty neat! I was always amazed that SGI took the dumb decision to put incandescent bulbs there originally.

There was no such thing as a white LED back then, and anything other than red/amber/green was pretty hard to come by as well.

But then the question becomes: why did SGI have to have white?

I put green LEDs in my (green) Octane's lightbar and quite like the green on green look. (I plan to do a blue lightbar if I ever get a blue Octane2.) Plus there's the whole stop/go connection with the red/green lights. A green LED from the start would have made more sense to me than what SGI did.

Nice work, japes! Very tidy modification you did to yours. And I never would have thought of mixing colours of LED to come up with a unique glow like you did.

Kumba wrote: don't think you have to avoid Debian. systemd is just going to be selected as the default init system upon install. You should be able to replace it with sysvinit after the install is complete.

Sounds right. A few weeks ago, a routine 'apt-get update' installed systemd and removed sysvinit from my Debian/testing system. I was not impressed with systemd; things just didn't work right. A simple 'apt-get install sysvinit' re-installed the old system. After that is installed, you need to run 'dpkg-reconfigure init' and purge systemd. (I'm not sure of the order in which those two things need to be done.) You could also choose upstart instead of sysvinit if you prefer.

Anyway, the point is, Debian Jessie certainly allows selecting between systemd, sysvinit, and upstart through the init metapackage. You won't break the whole distro, as somebody suggested...so long as you have the init metapackage and either sysvinit or upstart installed.

josehill wrote: At least in the past, Corel had demo versions of WordPerfect for various Unix systems, including IRIX, over at ftp.corel.com. I haven't looked for CorelDraw stuff, but maybe they have some info about it there.

Well, what do you know! The IRIX WordPerfect demo is still there at ftp://ftp.corel.com/pub/WordPerfect/wpunix/60-5.2/demo/sgi/ . There are demos for other Unix platforms, too, up a couple of directory levels.

All I can find at ftp.corel.com for CorelDraw on Unix are some text documents at ftp://ftp.corel.com/pub/CorelDRAW/DRAW_Unix/ .

A quick Google search (you got me curious, hamei!) shows a few other mentions of CorelDraw on Unix:

• https://groups.google.com/forum/#!topic/alt.corel.graphics/r8LygjBGX1s
• http://www.cnet.com/products/coreldraw-unix-v3-5-ibm-deca-sol-hp-sgi-cd/specs/
• http://umanitoba.ca/computing/ist/software/unix/applications.html#CorelDRAW

vishnu wrote: In the deep dark past I had Wordperfect 8 for Linux

Ugh. That brings back unpleasant memories. I briefly tried Corel WordPerfect for Linux. Never could get it running properly. And that was on Corel's own short-lived Linux distribution! (A Debian deriviative that I ditched in favour of the real deal.) Whichever WordPerfect version that was, it wasn't a native Linux application. It was the Windows version running in a heavily modified WINE environment, IIRC. The native IRIX version of WordPerfect is much easier to work with, IME, even though it's older (6.0 I think).

I hate to say it, but I've spotted two problems with autoconf 2.69.

First off, neko_autoconf-2.69 (from beta) and neko_autogen-2.68 (from current) both claim to contain the "autoconf 5" package. I don't think it's right that they both have the same package name and serial number. (It looks to me like the autogen one is just a mis-named tardist file; autogen is one of the scripts in the autoconf package.) That will very likely cause problems for anyone who has 2.68 installed and wants to update to 2.69.

The other problem is that the autom4te script in neko_autoconf-2.69 complains about not being able to find the m4sugar/foreach.m4 file. So I think there's (at least) one file missing from the tardist. (The m4sugar directory exists and contains other files.)

Unfortunately, that means I vote "no" for autoconf 2.69 in its current form.

Thanks for those builds. It's nice to see I'm not the only one who still has a fondness for 4.x!

At one point I was going to build a bunch of freeware for 4.x myself, but I never seem to have as much time as I'd like with my SGIs.

Thanks again, foetz. That last set of packages is impressive. I know I'll be able to put wget and ntp to good use. And some of those libraries will likely ease porting some other stuff, too. Great work!

Very nice! I've always had a soft spot for the Indigo2 Impact machines and yours appears to be in nearly perfect cosmetic condition. That's amazing.

Getting all the accessories and CDs with it is a very nice bonus, too. Have fun with it!

vishnu wrote: Is classic shell a separate install or a mode of the existing windows explorer?

It's a separate (third-party) install. http://www.classicshell.net/

Is it my imagination or is the Nekoware "primary mirror" ( http://nekoware.dustytech.net/index.php?path=beta/ ) out of sync with the one at http://www.nekochan.net/nekoware/index.php?path=beta/ ?

When looking for neko_autoconf-2.69 I found that the dustytech.net mirror still has package version 5, dated 07-08-13 in /beta while the page at nekochan.net has the newer package version 6 dated 29-09-14 in /beta. I haven't looked in too much detail to know if other mirrors are affected, or if other packages are out of sync too. But it seems the nekochan.net copy is more up to date than dustytech.net. Is something weird going on with the mirrors?

hamei wrote: wasn't there something odd about autoconf 2.69 ?

Yep. And canavan uploaded a fixed tardist more than two months ago. I knew he said he'd uploaded it and I wanted to test it out, so I didn't stop looking until I found it! If it hadn't been for that fact, I doubt I would have noticed the mirror situation.

My first thought was that I was mis-reading something or looking at a cached copy. Thanks for confirming it's not just me!

Hamei, it looks like you've got the libdvdread package from /beta installed. All the libdvdread.so.4* files are just symlinks to the version 5 library in that package. Check with 'ls -l'. Also, if you do 'elfdump -L /usr/nekoware/lib/libdvdread.so.5.2' you'll see in the IVERSION field that it is indeed sgi5.2 (or similar) instead of the sgi4.0 that mplayer is looking for.

I'm guessing that Axatax linked mplayer against the version of libdvdread from /current instead of /beta. And this looks like one case where the library symlink trick isn't good enough. The runtime linker is looking inside the library for version numbers rather than just at the filename. In that case, there's a problem (IMHO) with the dependencies in the mplayer beta package: it should depend on neko_libdvdread serial number = 1 rather than >= 1. Or, if the newer libdvdread package is compatible, the binary could be re-linked to it.

I finally had a chance to (briefly) test the revised autoconf-2.69 package today. So far all is well. It doesn't exhibit the problems I saw with the previous one.

This one (serial number 6) gets my vote for moving to current.

Thanks, canavan!

recondas wrote: In either case, at this point I can only express my appreciation to dclough for his efforts to have provided that service to *all* of us.

Me, too.

It wasn't my intention to seem ungrateful when I started this thread. If I came off seeming like it, then I apologize to all of the mirror providers. It wasn't supposed to be taken that way.

nongrato wrote: What is the real capacity of these? System detects 1024 megs, but from my understanding 1024 can hardly be divided by 12.

That sounds right. Each bank of 6 DIMMs is 512MB. Don't think of them as 6 distinct DIMMs; it's more like two groups of three pieces each. Geoman's remark about "cut-in-thirds Octane" DIMMs probably isn't too far off the mark. The Visual Workstations are known for their weird DIMMs!

See also the Visual Workstation 320 Owner's Guide on SGI techpubs . The memory chapter has some info on valid configurations. Yours is the maximum supported. Also, the Appendix on Technical Specifications suggests that the DIMMs are 48 bits wide each.

hamei wrote: libspeex ? wtf ? Not in current, not in beta.

Anybody want to chip in to buy hamei some new reading glasses?

There is indeed a neko_speex-1.2rc1.tardist file in beta and it looks like it's been there for more than 5 years. (It's dated 24-10-09!) There's an even older neko_speex in current, too.

nongrato wrote: The wikipedia page states that the maximum memory per module was 96Mb which gives us 1152(96*12) in total.

The Techpubs document says that the maximum memory modules are 16M x 48 parts, which does multiply out to 768 Mbits or 96 MBytes as Wikipedia suggests. But that doesn't account for the ECC (or whatever) overhead. Using six of those 48 bit modules gives an overall width of 288 bits, but the SGI documents show a 256 bit wide memory bus. So apparently they used a lot of bits (32 of them) for parity, ECC, or whatever other internal (non-user visible) purposes SGI has for the memory on these machines.

I recently spotted this SPARCstation 20 on ebay and it looks rather unusual to me. Does anyone here know any more about this particular type of machine (which doesn't appear to be a standard SS20)?

Unlike most SS20s, this one has two 25-pin serial ports on the back (labelled "Serial A" and "Serial B" where my own (more conventional) SS20 has one 25-pin port labelled "A/B". The ebay machine's second serial port is where the 13W3 for the on-board graphics belongs. There are also two unusual external connectors on the back panel where the plates for one MBus and one SBus slot belong. The interior photos show a very different motherboard, too. It's missing the extension on the last two DIMM slots, so it can't accomodate the VSIMMs. Plus, the MBus slots and two of the SBus slots are all blocked by a CPU module with a large plastic shroud. To me, it looks a lot more like an UltraSPARC CPU than any MBus module I've ever seen.

I'm not planning on buying the machine or anything. It's just got me curious as to why it's so different from other SPARCstation 20s that I've seen. Has anybody ever seen one like it? Are the differences purely in appearance or is it functionally different somehow?

hamei wrote: With the cover off, you can see that the disks don't spin up until they are addressed. I always thought they spun up at power-on but no. You can watch the bootup terminal display; when the process gets to each adapter, then the disks are powered up. Not sure if this is true for the boot disk but observed it on a secondary adapter.

For what it's worth (probably not much!) that's usually controlled via jumpers on the drive itself. If you have a large number of drives in a single enclosure the in-rush current from them all spinning up at once could be too much for the power supply to handle (even though it would be fine with them all running in a steady state). So the disk manufacturers provide a way to avoid the problem.

The manual for your exact drive could tell you more, but my Seagates have two jumpers to control spin-up. Normally no jumper is installed and the drives all spin up immediately at power on. Or you can put a jumper in one position and the drive will wait for the host to send the SCSI "Start Unit" command. (Which is likely the behaviour you saw.) Or you can put a jumper in another position (maybe a host doesn't send the "Start Unit" command) and the drive will power itself up after a delay that's calculated by taking the drive's SCSI ID number and multiplying it by 12 seconds (so drive 0 after 0s, drive 1 after 12s, and so on). Either way, the delayed spin up avoids problems caused by needing too much current at power on.

I think it's kind of clever and shows that some thought went into designing these things for a variety of situations.

Thanks for the info, guys! I'd never heard of the Cycle upgrades and didn't see their name until robespierre pointed it out. It's certainly some interesting hardware.

Are the "P1" and "P2" connectors perhaps a standard Pertec tape interface? Connecting a Pertec interface to anything more modern than the ISA bus could be a challenge. As robespierre mentions, that's more likely to be found for Unibus or the like. But there are ISA cards available on ebay such as this one (16-bit) or this one (8-bit) . (Assuming, of course, that it is a Pertec interface.)

Pertec-to-SCSI interface adapters might exist.

It's also possible that 25-pin connector is a parallel port. Some people have mentioned a parallel interface on the OD3201 for use with PCs; others say it's Pertec only.

Axatax_ wrote: I'd like to know if there is anyone else besides Hamei that has tried this release.

Yes, I did a month or so ago. (When Nekochan was down, and so I forgot to post about it when the site came back on-line.) Other than the speex dependancy, I saw no problems with the mplayer package in /beta. It played about half of the videos I threw at it. The other half just displayed a black window. But those videos all show the same behaviour on my Linux box, too. So there's nothing wrong with the SGI/IRIX/MIPS Pro port of the code. MPlayer behaved consistently across platforms and for that reason I give the /beta package my stamp of approval (and give you my gratitude).

Is fx automatically creating seperate / and /usr partitions with 5.3? I saw a similar error when first trying to install 4.0.5 on an Indigo. The default size of / was tiny and a full install of everything needed about 1.5 times the alloted space. So I used fx to manually repartition the drive using twice the default amount of space for / and everything worked. IIRC when you're in inst if you do a "list" between "install default" and "go" at the end of the output it will tell you how much free space you need on each of / and /usr so that you can check to see if that's your problem.

kshuff wrote: Still can't figure it out. In inst after doing an install default, then list, I get...

Code: Select all

Disk space summary (Kbytes)                 /          /root
Selections net change              0        252267+
Space available                    10771      22363

Code: Select all

root on dev 128,17; boot swap file on /dev/swap    swplo 50000

Mounting Filesystems

/dev/miniroot         on /
/dev/dsk/dks0d1s0  on /root

Neither of those show a /usr partition being mounted nor how much space is required on it. So it looks to me like everything is being installed to / instead of split across / and /usr. I think you've missed a step in fx, but I'm not familiar enough with it to know exactly which step. I think that /dev/dsk/dks0d1s6 should be your /usr partition, but either the filesystem wasn't created correctly or it hasn't been mounted correctly.

guardian452 wrote: Now I have used duck duck before but I never in a meeleon years would have noticed that, much less clicked on it to find out what it does. I always thought three strips was something the germans put on their running shoes and how do you come up with "settings" from that??

It's fairly common. (That still doesn't mean it's logical, though!) Firefox, Thunderbird, and Chromium (at least their Linux versions) all use the same "3 lines" icon for "Settings". Probably lots of other software, too. Those are just the examples I can see in front of me right now. It took me a while to figure out what the icon was the first time I encountered one.

How far after boot do they hang? Is it perhaps failing when trying to bring up the graphics system? I would expect the Octane 2 installation to be configured for VPro graphics and the older Octane 1 systems to have Impact series graphics which would require different software. At least that's the first thing I'd check.

Does the directory /usr/gfx/MGRAS exist and contain anything on your Octane 2 installation? If not, that would suggest that you don't have the right software installed to drive the earlier Octane graphics.

Hmm...I'm a little surprised at how quickly it hangs. I'm not familiar enough with the internals to know if the boot-time text port requires device-specific drivers. If so, then that would explain the hang, since you don't appear to have the right software installed for the older-style MGRAS graphics.

Have you tried booting the "hanging" machines with a serial console? It's possible that they're booting fine (not actually hanging at all) but can't display anything giving the appearance of being hung. I've certainly seen that sort of thing happen.

AFAIK, you'd need IRIX media in order to add the necessary graphics drivers to the existing installation. (Or a fresh install of IRIX on the other machines would also work.) But since you're cloning a disk, I'm assuming you don't have IRIX media. In which case, I'm stumped. Maybe somebody else will come along and offer better advice.

uunix wrote: On SUN machines you could boot -r and configure new hardware, do we not have anything on IRIX like that?

Something like that would require having all the necessary drivers on the hard drive already. Upthread it seemed clear that you don't have the MGRAS drivers, so to "configure new hardware" will require installing drivers from IRIX distribution media somehow (directly attached CD, DINA appliance, whatever).

The thread vishnu pointed out suggests that in inst (which you should be able to get to through the maintenance menu), you'd need "keep *" and "install fresh". I thought it would have been "install hardware" instead. So if "install fresh" doesn't work, try that.

Keep in mind that rackmount equipment is generally designed for front to back airflow. Cool air enters at the front, and hot air is exhausted out the back. Your closet setup appears to be using natural convection to create a bottom to top airflow, which won't necessarily help the computers.

I have some small but noisy 1U rackmount servers running in a home-built sound-proof enclosure that's much smaller than your closet. When I first put the machines in there, it took less than 5 minutes for them to generate enough heat to trigger the overtemperature alarms. That's when I realized that despite having font to back airflow through the box, a good deal of air was recirculating inside the box. Heat was being exhausted out the back of the machines into the enclosed space, and then being sucked back in through the front of the machines (instead of room air being pulled into the box). Since it was a small sound-proof box, I was able to put some scraps of foam around the servers to block air recirculation inside it. The machines haven't overheated since. The servers' own fans are enough to pull ambient air in through the front and exhaust it out the back of the box now that there's no chance of recirculation inside it. I didn't need fans in the box once that issue was fixed.

Now, doing something similar in your closet is going to be a lot harder because of the larger space involved. But I'd recommend doing whatever you can to block the hot exhaust air from returning to the front of the closet. Blanking panels of some sort in the rack itself, foam or insulation or whatever around the sides of the rack, etc. Maybe even some sort of panel above the door and rack to block vertical air movement in front of the rack. As you've got it now, air can enter at the bottom of the door and flow straight up to the output vents at the top without ever going through/behind the euipment (if I understand the setup correctly).

Try to guide the hot exhaust air from the back of the equipment to those upper vents and make sure the only path the cool intake air can take is through the equipment.

ivelegacy wrote:

foetz wrote: also going from extreme to impact requires a new backplane and a new psu so the switch is not cheap at all.

why ?

Because the Impact series graphics cards have extra power connectors that must fit into corresponding sockets of the backplane. The older systems don't have those on their backplanes. Of course, the PSU needs to be upgraded to handle the extra current that can flow through those connectors. There's also a direct cable from the PSU to the backplane in the Impact systems.

There are a couple of Indigo2 backplanes on ebay right now. There's a non-Impact one here and an Impact style one here . In the photos notice how the Impact backplane has a row of white connectors running vertically down the middle of the board. Those are why you need a different backplane for Impact graphics.

And just to be really confusing, the R10K Impact systems need an even more powerful PSU than R4K Impact systems. There were different PSUs for dual-head systems, too. See the "Powersupply" chart at http://hardware.majix.org/computers/sgi.indigo2/ for more info if you're curious.

ivelegacy wrote: about GPC, i haven't understood which library should contain these symbols
[...]
the binary GPC ends with this result

Code: Select all

gpc hallo.pas

ld32: FATAL   9  : I/O error (crtend.o): No such file or directory
collect2: ld returned 32 exit status


Well, it's telling you that it can't find the crtend.o file, which is likely where you'll find the needed symbols defined. So the real question is, where is the crtend.o file?

Since the hint that foetz gave you earlier in the thread didn't seem to help, I'll be more blunt: you'll need the "Development Foundation" and "Development Libraries" CDs from the full Irix install set. There are many things on those CDs that are required in order to have a fully functional compiler. It doesn't matter if it's a C compiler or Pascal, from SGI or an open source one. They all need the same development foundation and libraries installed from the operating system CD set.

vishnu wrote: The build instructions for netsurf look like a major PITA...

There's a thread on here from a year or so ago with instructions from when I tried to build NetSurf on IRIX. It is possible to build libdom with GCC on IRIX.

However, that's not necessarily the same libdom that's required. There could be another library with the same name. It might be worth trying, but it's also not necessarily going to work.

Since this seems to be from Ian Mapelson's "Gifts" CD, perhaps he'll weigh in with more (correct!) info about where to find the needed library.