The collected works of rosehillbob

While you are mirroring don't forget about ftp://oss.sgi.com ... The source code for Inventor lies there in the project directory as well as other gems..

I do have a vintage prom/eprom burner setup for 1980 to 1995 prom types. What kind of prom is it and I will look and see if my burner supports it.

Well I just looked it up in my manual and it says it is able to program the the Xilinx 17xx series of serial EEprom. I can only program the 8pin Dip version. I can't do any of the surface mount types - No socket... I never tried program burning a serial EEprom before so I can only assume it works OK.

I just purchased three xilinx 1765DPC serial eeprom chips the 8 pin dip type... My burner will program will program these chips. I will mention one catch... These chips are supposed to be NOS. This particular xlinx series of chips has one unique feature. You can after it is programmed set so it can never be programmed again! I mention this so don't buy too many chips and a burner unless you are sure the chips you are buying have never been used. I mention this because the seller on Ebay says this are NOS but doesn't know if any of them have been programmed before. Therefore I bought three hoping at least one has never been used. I should get them next week and will post the results of success or failure.

I just finished building the GNU ADA compiler 4.7.4 on Tru64 5.1. The compiler also includes the 'C' (no C++ didn't build it but you can add it from source) as well. Where do I upload it if anyone is interested in a copy?

I just now uploaded the ADA compiler to the incoming directory. It consists of two compressed tar files. One file is marked gnat-4.7-alpha-ev4-bin.tar.gz which will run on all Alpha's running Tru64 (maybe even in a emulator running tru64) and another file marked "gnat-4.7-ev6.tar.gz" which is optimized for 264 alpha's running TRu64 (these packages were built on a 264 Alpha ...My last Alpha still running!!).

Thanks for moving it to a drop box. Someone ask in the thread yes this is built from the standard GCC source which includes ada source since the 3.2 release of gcc. If you want an fully validated ADA compiler you can download the source from http://libre.adacore.com and build it yourself with this ADA compiler and while your at it you can build a complete graphical IDE environment.

vishnu wrote: What we should do n order to compile this "modern" shite on our SGI's is to write and compile binary patches to MIPSPro that add the functionality that C and C++ now possess, that MIPSPro doesn't. Difficult? Yes. Impossible? Probably. Now, who's with me? Into the fray!

WELL IT'S ALREADY BEN DONE! Let me explain. Oh about three months back I was busing looking into getting QT 4.8.5 working so I could build QTWeb. At this time I found out the areas the MIPSPro7.4m and GCC4.7 compilers were weak in. The Mipspro compiler was very fast,stable but the didn't support the latest C++11 syntax. The GNU compiler on the other hand supported C++11 syntax but while attempting the QT code would generate "internal compiler errors" plus it was very slow...It took twice as long to compile large C++ programs compared to Mipspro. At this time I had a choice of looking for a different compiler or start debugging the GNU compiler. I stumbled across LLVM which support MIPS big and little endian. I currently works on Mips Linux so I needed to get it to work on SGI. In the process of configuring it the configuration test programs said I was running "CLANG" but with obsolete version 6.0 of stdc++ libraries ...What the heck!
I did some checking and found out the front end code of MipsPro was acquired by Apple. Apple enhanced it, changed the name to "CLANG" and hooked it up to LKVM as the backend code generator and posted all the changes back into LLVM site. The LLVM fully supports three targets ...mips,intel and arm.
A group on the internet posts builds of the Linux kernel for the MIPS le and be built using the LLVM compiler. The kernel runs is reported to run faster than one built with GCC.
What this means right now people are basically running an updated version of our MipsPro compiler under MIPS Linux!
I think we should get the compiler working back under SGI!

foetz wrote: no prob at all and for installing it, unlike the workstations, you need to do it via serial anyway

Actually that statement is incorrect. You can and should install OS without serial cable on a ONYX2 (assuming it has Infinite Reality card set) to get the Xserver properly setup.

I decided to take a break from porting GCC4.80 and take a look at why Firefox3.5 not working. I didn't some testing of the libraries in found faults in GTK>=2.6 and a faulty DBUS library currently in Neko beta. I have a fixed GTK2.10.14 with cairo 1.8 now. I working on DBUS now and hopefully will have something working later today.
I did a quick check to see if Firefox 3.5 would compile OK and quickly came to a conclusion I will need a patch to build it with GCC. I was wondering does anyone have one for Firefox 3.5 or later?
I didn't try compiling Firefox 3.5 under Mipspro. Does anyone know if it will build under Mipspro 7.4m without a patch?

I decided to use gtk2.10.14 to do testing (yes I did test/fix a file handling bug) simply because Firefox3.5 requires gtk >=gtk2.10. I decided not try any later version simply because firefox3.5 must have gone under a lot of testing with gtk2.10 before release. The other library I need to test is DBUS. The use of DBUS was added in firefox3.5 and later. Currently every version of DBUS fails its own validation suite whether compiled with gcc or mipspro. The version in Nekoware also fails the validation suite so I assume the builder didn't test it. The Library is used for communication between process so the predicted result right now is firefox on startup would display a blank page but the moment it tries to render a page over the internet and launches a background process to prefetch DNS lookups it will core dump. This is my prediction even through I have never seen Firefox3.5 on IRIX and from what I read in post's that prediction is correct.
I hope to have a debugged DBUS in a couple of days and hopefully someone will send me a diff file to compile firefox3.5 or 3.6 with either gcc or mipspro or this will be a wasted effort.

Which version of firefox3.5 are you using for the build? I have 3.5.09 and with gcc it stops with message cc1 error '-march=-mips2' not compatible with the slected ABI. If try mipsPro7.4m i get 'as unrecognized option -_ASM'.
I gather from the above post 'ac_add_options --disable-safe-browsing' is a minor change to make things build...that is not what I am seeing here.
Note I did try a simple patch and got past the compiling this particular file with gcc only hit another road block (failed to link NSPR), made a second patch to links NPSR only to find a link problem in JS and so on. The rate I am going I will have to make dozen's of source code changes to just get it to build then comes the fun part of debugging it.
Is that your experience with 3.5?

I just notice something interesting on the Mozilla site concerning the requirements to run Firefox version 22. It states for the Linux platform DBUS isn't required to run but is listed as a "optional library to increase performance". I next downloaded the Firefox source code for 22 and found in the configure program the check for DBUS is still there! Hmmm... so DBUS is required to compile but not required to run (at least for the Linux case) so this must mean DBUS is loaded via DLOPEN! If that is the case and I am pretty sure IRIX supports dlopen as well so maybe a test of possible DBUS problems is to simply uninstall DBUS after you build Firefox3.5 and see if Firefox3.5 starts up without link errors. If it does well that is one way to see if DBUS is at fault!

I downloaded ff3.5.19 and diegel's patch and attempted a build. The build stopped at xpcom saying unable to build a stubsdef... file. I found the missing file in dexter1's xptcall patch. I added the file only to find it the IRIX assembly files in xptcall wouldn't assemble without error. The fault ended up being gcc was calling the gnu assembler and the gnu assembler was choking on the syntax. The solution was to modify Makefile.in to use the system assembler instead. I also modifed Makefile.in in security/nss/lib/freebl as well so the build continues to the end without interruption. I was now able to attempt to run firefox. What happens is it shoots a bunch of messages about registering various components then display several assertion failed messages and does a graceful shutdown (it doesn't crash with a bus error or dump core) instead display memory stats while shutting down. I did check the above link since the missing file is related to the above bug report link. Bugzilla resolved the problem with the change in GCC 3.0 abi by a patch which reads the stub file and generates the necessary C++ decoration on the fly. Diegel's patch uses a 'hand modified stubs file' todo the same thing. This file was missing in diegel's patch so I used the one from dexters patch file which may or may not be correct. I plan to implement the change tonight listed in bugzilla tonight to see if it corrects the problem...Building takes hours whenever a change is made. I calculated using an Onyx2 added $2 to my electric bill so far so I may have to pass the hat if I need to do a bunch of debugging!

I examined the patch in the posted link and the way it decorates the function although coded although different has the same result as the current patch. The test "testxpcinvoke" works correctly so XPCOM is OK. The next thing I tried was to enable the use of DBUS which is the default build. I expected the code to fault in DBUS but before it did twice as many components successfully registered(and three times as fast) as compared to when the code is compiled with DBUS disabled. It looks like the next step is correct the DBUS library before go any further with debugging Firefox3.5.

I examined the link above and the changes to xpcom basically do the same thing as the xpstubsdef file. The test program for xpcinvoke executes correctly therefore xptcall isn't where the fault lies. I did another check and this time built it with DBUS which is the default. Now the DBUS in Nekoware is faulty - fails it own tests with core dump - but with it enabled firefox3.5 registers three times as many components including ones that failed before (Firefox stops with DBUS dumping core). I will now look into DBUS and do some low level debugging to get a IRIX port working.

I have been doing some looking into DBUS I noticed a problem with g_spawn_async (from GLIB). I also did some research and found out with the introduction of libxul with FF2.0 Mozilla is relying less and less on NSPR and more on GLIB in the UNIX ports. Glib has multiple variations of g_spawn and depending on which ones Firefox or DBUS are using the outcomes will be different. I suspect Firefox3.5 without DBUS enabled is using GLIB to spawn processes and DBUS is using GLIB as well but there is more than one function call. Remember the fault of Firefox3.5 without DBUS enabled is it fails to start new a process ( a listener) and times out with an error unable to communicate to the listener. Well to get DBUS to work I have to get a proper working GLIB which may solve some other problems. Firefox with 'tests_enabled' builds a whole host of test programs. The test programs associated with inter process communication all fail . I haven't tried out the javascript test programs yet...I think more of firefox must work first.

I just got two EV47's missing the hard drives. I got new drives and tried to install tru64 5.1B Well didn't get to far attempting to boot from either a CDROM or RIS server it reads the boot loader OK but hangs with "jumping to bootstrap code". I gather from from searching the need you need "New Hardware Delivery Kit 7 (nhrd7)" or tru64 5.1B-6 kit 8 which contains nhrd7. Again searching the net the kit used to be a download from a Compaq then HP site but when HP cancelled support of tru64 the site was removed.

Anyone out there have the missing software? Right now I have two very nice boat anchors!
Before someone asks the option to use OpenVMS is available but you can't get Hobbyist license anymore. Redhat
Linux did support EV47 but to load it you need a "wrapper kit from Compaq to install it" which also is gone.
Of course if anyone has the wrapper file I can probably Red Hat linux 7.2 to install.

I still don't have tru64 installed on a EV47. In a previous post a titled "Tru64 failing to install EV47 - makes for nice boat anchors!" I was pointed to where to download "new hardware delivery kit 7". I downloaded the file updated my RIS server but no change. It looks like my tru645.1b installation disk is to old...The date of the genvmunix file on my install CD October 16 2002. I need a newer install disk. Everyone please check you tru64 5.1b install disk and see if you have a newer version. Before you complain about sharing software I already contacted HP...HP has no software ... sold it all! If you find a later version please make an ISO image I can download and I will try again. I have two ev47's here .... I have a sweet deal for you. The first to get me a ISO image of TRU64 that install's successfully install on a EV47 I will give you a 'FREE EV47' you just have to pay for shipping! Note the EV47 is the fastest Alpha ever made. It is 7 times faster than ev56 (second generation a lot of people have) and 12 times faster than the original ev4 (ie Jensen). It sold for a mere $72000 in 2003.

I just downloaded and checked that image it is the same as the install CD I already have. The EV7 came out in 2003 six months after that build...

I am trying to install tru64 or openvms on a Alphaserver ES47 which has the EV7 processor. I have two such units I would like to get some OS on! The ES47,ES80,GS280 are the last models from DEC/Compaq/HP with a a Alpha processor and the only models with the EV7 processor.

I finally did get tru64 5.1b installed. I had to use RIS running on a "emulated Alpha" with tru645.1b and NHD7 installed !