The collected works of jpstewart - Page 2

My first guess is that IAT is assuming GNU-style getopt.h which is very, very different from IRIX's own getopt.h. A quick look (so I'm really only speculating about everything) at the IAC source shows an unconditional include of getopt.h in src/cmdline.c. There are no checks in the configure script to ensure that getopt.h is indeed GNU getopt.h and/or has the necessary features.

And there are, of course, corresponding differences in the implementation of getopt functions in GNU libc vs. IRIX libc. So just copying over the GNU header will not suffice. You'll need to drag in the implementation of some functions, by the looks of it. Perhaps from Gnulib.

So it looks like you've got a fair bit of porting work before it'll compile on IRIX. And that's just for the getopt stuff. Who knows what else the compiler will uncover after you fix that!

Indeed, that thread does have some useful tips. But in hamei's specific case here, the problem is more than getopt_long. His posted error is due to the lack of a struct option in IRIX getopt.h. So he'll need more than just the getopt_long implementation discussed in that thread. None the less, the approach described there is right on target.

Despite having an SS20 behind me at the moment, I am somewhat tempted at that price. I've seen one seller asking $200 for the 8MB VSIMM alone! In that context, this doesn't look like such a bad deal.

A few what? Full systems? VSIMMs? Something else?

From your message's position in the thread, it could be just about anything.

You might try contacting B&B Solutions in Laval, Quebec. I bought a G160 from them at a very reasonable price. Mind you, that was a couple of years ago so they might not have any more.

If they don't, I might be persuaded to part with mine. (It's not in use at the moment.)

G160 drivers are also available for download from Ian Mapleson's SGI Depot at http://www.sgidepot.co.uk/depot/

We need more info to help diagnose the problem with your setup:

1. Which graphics option is your SS20 using? Built-in SX? Turbo-GX SBus card? Something else?
2. What 13W3 to HD15 adapter are you using?
3. What brand/model of LCD are you trying?
4. Is your SS20 configured to output only to the serial console?
5. With no display, can you tell if the SS20 is doing anything at all? Maybe it's a more serious problem than just the display.

FWIW, my SS20 (with Turbo-GX graphics) has no problem displaying on my trusty old Samsung SyncMaster 760V LCD with one of these adapters .

Well, you've certainly been thorough!

The only things I can think of are that it might be a dead TGX card or the OpenBoot PROM is configured to use the on-board SX instead. (But I'm not an expert on Sun PROM settings so I'm not sure if that's even possible.) I'm rather busy with work at the moment, but if nobody else helps you get yours working by the weekend, remind me and we can compare PROM settings.

You certainly should be able to see the boot-up messages and console on the TGX. I do.

As to your question about changing the XConfig to use the TGX...what version of SunOS/Solaris are you running on it?

Wait...I just noticed that you said you took out a VSIMM. Did you do a 'boot -r' (from the OpenBoot prompt) at any point to reconfigure the system?

Indeed. There must be some piece of (expensive) software that's only "certified" on that hardware.


Be patient and keep watching. I got a C8000 off eBay for $100 (CAD) last summer from a Montreal-area seller. Dual-core 1.1GHz (with a second socket for a second dual-core CPU), 16GB RAM, 146GB SCSI HDD. The seller asked if I wanted any more than the one I bought at auction. He had two others that he couldn't sell. But that was 8 months ago, so they're probably gone by now.

Glad to hear you got it working!

I was planning to fire up my SS20 tonight to check NVRAM settings on it for comparison. Now I guess I need to find a different excuse to play with it!

First off, thanks for the download script, jan-jaap! I'm glad this old thread was resurrected, or I never would have found the script. And for a long time, I've wanted to download the collections that I think I might need.


It seems they've added new docs in some of the categories (especially hardware and Linux) since that was written (apparently in 2006). I've got the following sizes (also kB), dowloaded in the last 24 hours:
184952 manuals_0530
575280 manuals_0650
1216192 manuals_hdwr
475596 manuals_linux
74284 manuals_nt

I didn't dowload the other 6.x collections, so I don't know how they compare today vs. 2006.

The pair of sockets side-by-side are for optional TRAM (texture RAM) on the graphics board. The other group of three sockets lined up together are for ribbon cables to an optional video card. (In the SGI world the difference between "graphics" and "video" is important as foetz alluded to above.) So nothing is missing. You should have a fully functional base graphics board.

Now, for your main inquiry:

As jchamberlain suggests, it is very troubling that the Heart LED isn't lighting up as it should. It's equally bad that you're not seeing a red LED on the outside of the machine immediately upon powering up the machine (while power-on diagnostics are happening). Both of those facts suggest the problem is not with the graphics output or the connection to the monitor. I'd even be willing to bet that you won't see anything on a serial console, as it seems to be failing very early in the boot process.

The difficulties you had with the top clamp on the motherboard suggest physical damage to the motherboad, the frontplane or the connection between the two. Somewhere on this site you can find documentation on how to remove the frontplane and inspect the connections. I'm sure the search feature will help you find it. That's where I started when my Octane was giving me troubles (although your problems are more severe than mine were). Sorry I can't be more specific at the moment; but that's where I'd start looking before worrying about Sync-on-Green monitors or anything like that.

Do you have settings for CFLAGS and/or CPPFLAGS?

My guess (and it's just a guess at this point) is that you've got -I/some/path in your CFLAGS so that the compiler can find the file, but that it's not in your CPPFLAGS so that the preprocessor (when run alone) cannot find it. If you move -I/some/path to CPPFLAGS instead, you'll get the expected results.

That's certainly (IMHO) the most likely reason for the compiler and preprocessor to disagree.

I hate to resurrect a year-old thread, but I spotted another, identical Indy this morning. This auction listing tells us that it was pulled from a KLA-Tencor CRS 1010S tool, which is apprently a wafer defect review station. So it looks like robespierre's guess was very good!

Indeed, there are some weird ifdefs in sys/time.h.

I know that I've encountered the same problem in the past when compiling something. (Looking through my notes, I can't find it at the moment though.) In all likelihood, sys/time.h is already being included...but the definition of struct timeval is surrounded by ifdefs. IIRC (from memory and a quick glance at that header file), the quick and easy way to fix the problem was to add -D_BSD_TYPES to CPPFLAGS.

I could be wrong about the specific fix, but I know you're right, duck, about sys/time.h and ifdefs!

It's actually /usr/include/sys/time.h that duck mentioned...a completely different file. That's where you'll find the definition of struct timeval.


Which is not surprising. It was a vague memory of a past problem I had, and since I can't find my notes from whichever of my projects had that problem I can't be sure that was the solution. If whatever you're compiling isn't doing an #include <sys/time.h> then it cannot possibly help anyway. And, as duck said earlier, there might be even more "braindead ifdefs" to sort out.

Directly adding the definition as you did does no harm.

I don't know what's more impressive: the amount of skill required to draw that, or the amount of patience required to draw that. I have neither, so I'm in awe of both!

I'm another long time vi/vim user myself. And vim actually has a choice of GUIs if you compile your own. (See http://vimdoc.sourceforge.net/htmldoc/gui.html ) I found the vim GTK GUI (on a Linux box) to be a gentle way of getting used to vi/vim...even after more than 10 years of struggling with command-line vi. The friendliness of the GUI version let me get comfortable with it, and now I find it a lot more useable even when the GUI isn't available.

It's telling you that glib-mkenums is not installed. You'll need the neko_glib package installed (including the development stuff which might not be installed by default) to build pango. It's a shame that the configure step doesn't actually check for the presence of glib-mkenums!

Also (from my own past experience), glib-mkenums is a Perl script which might not run so well with IRIX perl. You might need to change its first line to use Nekoware perl instead of /usr/bin/perl5 (if you get more strange errors from glib-mkenums). That same advice applied to tools/gen-color-table.pl from the Pango source when I tried to compile pango-1.29.5. I had to change it to use a newer Perl, according to my notes from a past IRIX porting project. (Although my notes don't say why I felt I had to do that.) IRIX perl is just plain ancient.

I installed 1.28.4 on my Octane the other day. A few quick tests revealed no "show stopper" problems, but I haven't had time to test thoroughly yet.

I don't know whether or not my experience so far is enough to make another vote in favour. I'll let somebody else decide if this counts or not!

Is anybody else seeing strange, unprintable characters after some of the menu items? (See attached screenshot of the "File" menu.) On my Octane, they show up after some (but not all) of the menu entries, and it affects all of the menus I've seen --- not just the ones accessed from the menu bar but also the context-sensivite right-click menu.

I don't know if that's a problem with the Firefox package, or an upstream Firefox bug, or something wrong with my system (which is very possible). Anyone else seeing this? If not, then it's probably my system and I won't complain anymore in this thread.

I'll agree with duck that LD_LIBRARYN32_PATH shouldn't be a requirement. It sounds like the packager forgot to use the -Wl,-rpath -Wl,/usr/nekoware/lib option (or specified the wrong path) when building the software.

In another thread elsewhere here (which I can't seem to find at the moment), I was told point blank (by somebody more knowledgable than I am about these things) that it should be considered an error in the package if LD_LIBRARYN32_PATH was required for any of Nekoware; that rpath was considered the correct way to handle Nekoware library paths.

No. It is not. Read the rld man page for more information. It is clearly optional ("3. Use LD_LIBRARY_PATH, if it is defined in the environment at the time of execution" from that page, emphasis mine) and only used if the shared object was specified without a full path and it's not found in the specified RPATH (which may be empty). In other words, LD_LIBRARYN32_PATH is a fallback for when the executable doesn't supply library path info of its own.

And there's a hardcoded default path that's used as a fallback after that, that includes /usr/lib32 and other standard paths where you'll find the system-installed libraries. For many N32 binaries (such as those installed with IRIX itself) that is sufficient to find their shared libraries without needing LD_LIBRARYN32_PATH set after a fresh install.

So that should show that there's no "mandatory requirement" for LD_LIBRARYN32_PATH.

Besides, my Octane and O300 both run just fine without it set, including those Nekoware packages which set rpath as suggested in the Packaging Software Wiki page.

Thanks for the pointers, folks. I knew I was seeing the glyph for an unprintable character, but I didn't quite clue in that it meant that I needed a Unicode font. Maybe playing with the Octane at the end of the day when I was tired wasn't the best plan. Glad you guys were awake enough to spot the problem.

And so, I can safely say now that Firefox 3 is working fine for me. I haven't seen any problems with the Nekoware package.

While you're at it, have a look at the fstab(4) man page, and try combinations of 'hard' vs. 'soft' and 'intr' vs. 'nointr'.

The default is apparenly 'hard' which will make the system retry until the server responds. Maybe you'd prefer 'soft'?

You can probably interrupt it with a suitable signal thanks to the 'intr' option being on by default...unless that's been changed on your system.

In addition to the Nekochan resources the other posters have mentioned, I'll add that Ian Mapleson's site has additional information at http://www.sgidepot.co.uk/sgi.html#ADMIN . There's tons of stuff on his site that you'll probably find useful if you're new to SGIs and IRIX.

Fuel: no, it's single processor only.
C8000: only if your CPU(s) have the L2 cache. AIUI, the 1.0GHz PA-8900 with only L1 cache only supports a single CPU, while the CPUs with 64MB L2 cache (in both 1.0 and 1.1GHz models) support two sockets. Note, however, that the PA-8900 is a dual-core chip so even with only a single-socket populated, you still have two cores. (A two-chip, four-core C8000 is everyone's dream, though, isn't it?)


The Ultra 45s have really, really held their value well. I've never seen one at anything approaching an affordable price. You might consider backing off a step to the slightly older Sun Blade 2500. After seeing all the Ultra 45s for a couple thousand bucks, I got myself a Blade 2500 (2x1.28GHz, 8GB RAM, XVR-1200 graphics, 18GB HDD) for very cheap (under $50) instead.


If you're patient, ebay can be great. I still haven't found a great deal on an Intellistation myself, but all the systems in my signature have come from ebay. And most were under $100 --- including both the aforementioned Sun Blade 2500 and my HP C8000 (1x1.1GHz, 16GB RAM, FireGL T2 graphics, 146GB HDD). In my experience, if you wait for the right auction you can get a great deal.

Is there an "-liconv" option somewhere in the link command? It's quite possible that the linker could find libiconv...if somebody (i.e., the Makefile) bothered to tell it to use libiconv.

(Blame it Linux-centric code/developers. The iconv functions are part of GNU libc and thus don't require an external library to be linked on a Linux box. So the Makefile may never have asked the linker to look for an external libiconv.)

The single-link DVI specification supports a maximum pixel clock of 165MHz. Recondas' 1920x2400 resolution used a low 33Hz refresh rate. Multiplying 1920x2400 pixels times 33Hz gives 152064000 pixles/second, or about at 152MHz of bandwidth required. So it's actually well within the spec for single-link DVI.

In other words, the unusually high resolution is nicely offset by the unusually low refresh rate.

Thanks for sharing the details, recondas. It also nicely answered guardian452's question about porches. (Which I had completely forgotten to account for, obviously!)

But at least it's still within spec for single-link DVI.

Neat effect! I downloaded the wallpaper file from your linked site to have a look at it in more detail than the photo. I really like the way the neatly arranged grid of dark spots makes the image look like its on some sort of perforated material. I couldn't see that level of detail in the photo of the whole desk. It looks like you've got a really nice setup there.

You need to put maxwell.o before the list of libraries. The linker searches libraries in the order specified to see if they can be used to resolve any of the still unresolved symbols. Since you listed the libraries first, there were no unresolved symbols at the time the linker looked at them. Then it looked at maxwell.o last and complained about all the unresolved symbols in it. Try:

Note that I'm assuming the *.a archives will be needed to resolve symbols in maxwell.o and that the standard X libraries may in turn be needed by the *.a archives.

I'd love to know how the Chinese price list compared to one of a similar vintage from North America. I wouldn't be surprised if those prices were 5 to 10 times higher than the rest of the world.

If it's not firefox-bin, then it might be xulrunner (or some variant thereof such as xulrunner-bin). None of my IRIX boxes are currently powered up so I can't check the Nekoware package myself. Have a look and see what you've got that starts with xulrunner, though.

The 'firefox' executable is actually just a short shell script which launches the real executable (after setting up its environment), so if all else fails have a read through the script and see what it calls.