The collected works of stuart - Page 2

The commands in the test-suite which produce this output are:

Code: Select all

# test some simple floating point formats
printf "%4.2f\n" 4.2
printf "%#4.2f\n" 4.2
printf "%#4.1f\n" 4.2

printf "%*.*f\n" 4 2 4.2
printf "%#*.*f\n" 4 2 4.2
printf "%#*.*f\n" 4 1 4.2

printf "%E\n" 4.2
printf "%e\n" 4.2
printf "%6.1E\n" 4.2
printf "%6.1e\n" 4.2

printf "%G\n" 4.2
printf "%g\n" 4.2
printf "%6.2G\n" 4.2
printf "%6.2g\n" 4.2
... so these aren't especially complex tests.

It's clear that the output the MIPSpro bash-3.2 produces is wrong - and it appears to be 'printf "%G\n" 4.2' that hangs.

My current GCC build of bash [3.1.17(1)] outputs "0" when the above command is run (which is also wrong), and running the new build of 3.2 and running the same command also causes bash to lock and need a "kill -9" to abort the process.

Update
I've just spent the eveing rebuilding bash with just about every combination of flags, and the (neko) GCC versions always output 0 when reformatting floats with printf. For me, MIPSpro versions always hang on the same test. Could someone with freeware GCC installed please try building with this?
joerg wrote: Somewhere reportet minor errors with about xchat-2.6.8. I used it here on my fuel and the basic stuff works. IIRC the problem was also reportet on other platforms as well... i would like to say move it into current.


As noted here:

http://forums.nekochan.net/viewtopic.php?t=12691

... the UI in xchat 2. 6. 8 is (admittedly on all platforms) quite horribly broken - so even if this package does match the latest release, it's still no good for actual use. Please could it be moved back to beta until upstream get their heads in gear?

Cheers,

stuart

Edit: Sorry, I meant xchat 2.6.8, not xchat 2.8.
QuicksilverG4 wrote: What might this strange sounding item be? :)


I've got one of those!

Complete, with all printed pages and CDs, too. Strange really - seems to be a development tutorial/walkthrough told as a nursery rhyme or children's story.

I couldn't imagine anyone doing anything like this nowadays - which makes it sorta cool.

Don't think it has any relation to DWB, though :D
Could someone update the 'descript.ion' for the beta directory?

It has "neko_spl.tardist" when the file is named 'neko_spl-1.0rc3.tardist' and "neko_links-2.1pre26.tardisrt" when the file is named 'neko_links-2.1pre26-1.tardist'.

Cheers!
Therion wrote:
However there is yet an unresolved issue, when you go in windowmaker which works very well the tiff images have all a black background and no transparent one.


I remember encountering this a while ago (2004!) on Gentoo on Linux. I've managed to dig out the Bugzilla entry:

http://bugs.gentoo.org/show_bug.cgi?id=75316

... which points to a patch at:

http://bugzilla.remotesensing.org/show_bug.cgi?id=718

... which no longer seems to be online :(

So far as I can tell, libtiff-3.7.1 (which is also the Nekoware version) has a transparency bug. The latest release seems to be 3.8.2, which is unaffected.
Alver 's working on an updated gaim-2 built against a fixed version of libgcrypt (which is what causes the jabber crash).

I've successfully built gaim-1.5.0 from pkgsrc ( search for my posts on using pkgsrc on IRIX) and that works fine for jabber... just not for MSN.

<sigh>
porter wrote:
Mine leaps like Sam Beckett!

:lol:
I remember that you have to be a bit careful with your LD_LIBRARYN32_PATH setting with System Manager - if a different libdb is loaded (say, the Nekoware one rather than the IRIX one in /usr/lib32) then System Manager won't load, but you'll get an 'rld' error on your console.

I'm not sure this would account for loading delays, but it might explain the first part...
Quick note: Bear in mind that /usr/nekoware/lib == /usr/lib32 : /usr/lib is o32 libraries, /usr/lib32 is n32 libraries, /usr/lib64 is 64bit libraries. You probably don't need to worry about this - but it is important that /usr/lib and /usr/nekoware/lib never appear in the same variable... you should have:

LD_LIBRARY_PATH=/usr/lib:...
LD_LIBRARYN32_PATH=/usr/lib32:/usr/nekoware/lib:/usr/freeware/lib32:...
LD_LIBRARY64_PATH=/usr/lib64:/usr/freeware/lib64:...

I don't know about the delay, though, and it does sound wrong - does anything odd appear in /var/adm/SYSLOG?
Code:
$ ./notes -new
Notes: Error opening your $HOME/.notes directory.
Segmentation fault (core dumped)
$ dbx ./notes core
dbx version 7.3.4 (86441_Nov11 MR) Nov 11 2002 11:31:55
Core from signal SIGSEGV: Segmentation violation
(dbx) where
>  0 _closedir(0x0, 0xffffffff, 0x2, 0x0, 0x0, 0x0, 0x72, 0x10007c04) ["/xlv52/patches/7143/work/irix/lib/libc/libc_n32_M4/gen/closedir.c":31, 0xfa673b8]
1 App::loadNotes(void)(0x0, 0xffffffff, 0x2, 0x0, 0x0, 0x0, 0x72, 0x10007c04) ["/usr/people/stuart/devel/notes-0.9/Main.C":59, 0x10007bfc]
2 ::main(0x2, 0xffffffff, 0x2, 0x0, 0x0, 0x0, 0x72, 0x10007c04) ["/usr/people/stuart/devel/notes-0.9/Main.C":158, 0x10006e78]
3 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x10006ae8]


It seems to run fine if I first manually create a "~/.notes" directory, but seems to reliably segfault if this doesn't exist!
Great stuff!

I once messed around with VFC on my Octane, to see if a 2@1680x1050 mode was possible... but there seemed to be exactly zero documentation on building 2@ modes, I couldn't get it to work myself, and no-one else had ever succeeded!

In the end I just decided to stretch the budget and go for 2@1600x1200 - but I'd still be fascinated to know whether anyone's solved this particular problem.

(P.S. I notice that one of the available resolutions is 2@1920x1200 - does a 128Mb V12 really have enough memory to handle this resolution? I can already only use a 16bit (rather than 24bit) Accumulation Buffer due to memory constraints...)

(P.P.S. At what resolution is dual-link DVI required? Does the V12 DCD option provide dual-link?)
hamei wrote: Weird - my V12 shows a res of 1920 x 1200 x 50 in xsetmon and several others close to that.


Hmm - I have 72Hz, 60Hz and 50Hz for 2@1920x1200, but only 60Hz and 25Hz(!) for 1920x1200... odd.
Also, bear in mind that if you press the NMI (Non-Maskable Interrupt) button on an IRIX machine (or also if the kernel panics?) then the contents of memory will be written out to swap for later recovery by 'savecore', if enabled.

Since this is about as low-level as it gets, this data is written directly to the partition defined as swap in the volume header - so XVM/XLV concats (etc.) aren't honoured.

(... which is kinda annoying if you have 4Gb of swap split over two disks in a 4Gb machine :roll: )

It's interesting to note that IRIX conventionally uses partition 1 as swap, but that this lives at the start of the disk, immediately following the Volume Header, and with the boot partition following this. The reason for this somewhat counter-intuitive configuration is that, especially with older discs, the data rate is much higher closer to the spindle. Indeed, on ancient MFM and RLL discs, there was always an equal number of sectors per cylinder - resulting in high data rates near the spindle (where the sectors were most compressed) and a very low data rate on the outside of the disk (with elongated, low-density sectors). One wonders if, on modern disks, there would be an advantage to placing the swap partition in the centre of the disc, so as to minimise the average seek time.

(Although to arrange this correctly, you'd also have to take into account the disc's physical layout - e.g. how many platters are in use and the exponential increase in the amount of data stored in each track as the tracks increase in length, to ensure that you're in the centre of a platter rather than on an edge)

Changing the subject slightly, does anyone know how modern multi-platter disks arrange their data? Are they effectively a JBOD-type setup where the first platter is filled and then data starts being written to the second, or is it more like a striped setup, where head movement is minimised by writing as much data to the current cylinder as possible before moving on?
As noted here , phpBB's 'code' tag removes any leading spaces from a line - which, for code, is almost definitely not what's wanted.

Is there any phpBB setting which can be hacked/changed to preserve all line-spacing within 'code' tags?
Interesting - I can see spaces in your reply...

I pasted in the output from 'diff' in the post above ( http://forums.nekochan.net/viewtopic.php?f=15&t=16878 ) with neko_firefox-2.0.0.11, and I can't see any leading spaces!
It must be something about the characters in the text, then (the troffrc file does tend to look like line-noise ;) ) - I've just re-edited the post with Safari, and the message body definitely contains leading spaces... which the rendered version definitely doesn't.

So there's definitely something wrong here - but it's something which doesn't affect hinv posts or SOB's post above.

Code:
. <- test 0
. <- test 0
. <- test 1
. <- test 1
. <- test 2
. <- test 2


Ah-ha! There we go! Single spaces at the start of lines in code blocks are being dropped!
Do you have eoe.sw.cdrom, eoe.sw.udf, and eoe.sw.rm_media installed?
Hurrah!

Now all we need is a native MIPSpro build ;)

(P.S. Did a previously broken codebase work simply by changing to GCC 4.x, or had 2.4.1 not been tried before? There may be hope for a native build if they've fixed the problems... )
Yes! It works and it seems to be very stable!

(Especially compared with the last version of gaim I used, which crashed out all the time)

I built with MIPSpro from pkgsrc, but with only a few minor patches to libpurple the whole thing builds without issues - I'm impressed.

Since Adobe has released the specs for Flash, all we need is for gnash to catch up and then for the new no-assembly Java to be ported, and we're laughing :D
Having run pidgin 2.4.1 for 24 hours now, the only problem I can see is that the client-supplied icon isn't displayed correctly when Pidgin is iconified/minimised.

Does anyone have a decent pidgin/gaim icon that I can override this with?
Hmm - I wasn't aware of this... when I came across some code doing the same thing, I replaced the '[0]'s with '[]'s and everything built and tested successfully - although by the sounds of it, this may purely be good luck in that the code was compiled with '-c99'.

Of course, there could now be some deep-seated codepath which won't work correctly or will kill the app - but all seems good so far.
(I think I came across this with either pidgin or libpurple).
I've looked at eBid a few times - and the problem's always been that there's not actually anything of interest on there!

I guess it's a critical-mass thing... but if enough people start to move to eBid, then I'd be more than happy to abandon eBay and PayPal!
Not easily, I'm afraid - I built Pidgin via NetBSD's pkgsrc system and it's got a ton of dependencies.

(For those using pkgsrc, the pidgin build has a surprisingly large degree of just-worksness!)

When I have time later in the week I'll try to work out the minimum versions of the different dependencies, and confirm that they exist in nekoware. If all's good, I'll try a nekoware build and see how I get on.
For a pkgsrc build, I added the following two patches:

Code: Select all

--- pidgin-2.4.2/libpurple/plugins/perl/perl.c.dist
+++ pidgin-2.4.2/libpurple/plugins/perl/perl.c
@@ -627,6 +627,11 @@ init_plugin(PurplePlugin *plugin)
loader_info.exts = g_list_append(loader_info.exts, "pl");
}

+/* If we're not using GNU C, elide __attribute__ */
+#ifndef __GNUC__
+#define  __attribute__(x)  /*NOTHING*/
+#endif
+
#ifdef __SUNPRO_C
#pragma init (my_init)
#else

Code: Select all

--- pidgin-2.4.2/libpurple/dbus-bindings.c.dist
+++ pidgin-2.4.2/libpurple/dbus-bindings.c
@@ -3695,7 +3695,7 @@ purple_conversation_set_data_DBUS(DBusMe
CHECK_ERROR(error_DBUS);
PURPLE_DBUS_ID_TO_POINTER(conv, conv_ID, PurpleConversation, error_DBUS);
key = (key && key[0]) ? key : NULL;
-       purple_conversation_set_data(conv, key, data);
+       purple_conversation_set_data(conv, key, (gpointer)data);
reply_DBUS = dbus_message_new_method_return (message_DBUS);
dbus_message_append_args(reply_DBUS, DBUS_TYPE_INVALID);
return reply_DBUS;
@@ -3712,7 +3712,7 @@ purple_conversation_get_data_DBUS(DBusMe
CHECK_ERROR(error_DBUS);
PURPLE_DBUS_ID_TO_POINTER(conv, conv_ID, PurpleConversation, error_DBUS);
key = (key && key[0]) ? key : NULL;
-       RESULT = purple_conversation_get_data(conv, key);
+       RESULT = (dbus_int32_t)purple_conversation_get_data(conv, key);
reply_DBUS = dbus_message_new_method_return (message_DBUS);
dbus_message_append_args(reply_DBUS, DBUS_TYPE_INT32, &RESULT, DBUS_TYPE_INVALID);
return reply_DBUS;
@@ -4955,7 +4955,7 @@ purple_core_quit_cb_DBUS(DBusMessage *me
dbus_int32_t RESULT;
dbus_message_get_args(message_DBUS, error_DBUS, DBUS_TYPE_UINT32, &unused, DBUS_TYPE_INVALID);
CHECK_ERROR(error_DBUS);
-       RESULT = purple_core_quit_cb(unused);
+       RESULT = purple_core_quit_cb((gpointer)unused);
reply_DBUS = dbus_message_new_method_return (message_DBUS);
dbus_message_append_args(reply_DBUS, DBUS_TYPE_INT32, &RESULT, DBUS_TYPE_INVALID);
return reply_DBUS;
@@ -6723,7 +6723,7 @@ purple_prefs_set_generic_DBUS(DBusMessag
dbus_message_get_args(message_DBUS, error_DBUS, DBUS_TYPE_STRING, &name, DBUS_TYPE_UINT32, &value, DBUS_TYPE_INVALID);
CHECK_ERROR(error_DBUS);
name = (name && name[0]) ? name : NULL;
-       purple_prefs_set_generic(name, value);
+       purple_prefs_set_generic(name, (gpointer)value);
reply_DBUS = dbus_message_new_method_return (message_DBUS);
dbus_message_append_args(reply_DBUS, DBUS_TYPE_INVALID);
return reply_DBUS;
@@ -9602,7 +9602,7 @@ purple_util_format_song_info_DBUS(DBusMe
title = (title && title[0]) ? title : NULL;
artist = (artist && artist[0]) ? artist : NULL;
album = (album && album[0]) ? album : NULL;
-       if ((RESULT = purple_util_format_song_info(title, artist, album, unused)) == NULL)
+       if ((RESULT = purple_util_format_song_info(title, artist, album, (gpointer)unused)) == NULL)
RESULT = "";
reply_DBUS = dbus_message_new_method_return (message_DBUS);
dbus_message_append_args(reply_DBUS, DBUS_TYPE_STRING, &RESULT, DBUS_TYPE_INVALID);


Note that dbus-bindings.c is automatically generated during the build process.

There are also a small number of distribution patches, but these mostly seem pkgsrc-specific. There is a patch to link libpurple against ncurses, but I suspect that this isn't needed if libpurple is only used with Pidgin.
Just a quick note that dbus-1.2.1 from pkgsrc compiles and runs correctly, although a quick look at the package directory shows that they have developed several patches, some of which are IRIX-specific.

The website does say " D-Bus is very portable to any Linux or UNIX flavor, and a port to Windows is in progress. " so I suspect that it isn't in fact tightly bound to the X server... and it does work for me on 6.5.30 without dumping core.
Hmm - would it be possible to have a single Octane with an Odyssey graphics option installed for IRIX with an (E)SI also installed for Linux/X?

(Presumably a PCI card would be preferable, since IRIX will safely ignore it.)

Just curious...
Still here for me in 6.5.30!

Toolchest: Desktop -> Customize -> Background: CPU Eater

... just as you remember it ;)
I have a 300MHz R5200, but I've no idea whether there's a blue wire or not... is this a deal-breaker?
Oh - shiny!

My site's back up again now after a long outage due to my RAID array suddenly dropping several disks at once (I shouldn't have used five disks from the same batch...) - so it's at least possible to get a screenshot without a version warning :D

Might it be worth including sgisync too, to allow people to auto-download any patches for the version of IRIX they're about to install?

Great work,

stuart
joerg wrote: Well, the following mirros are (currently?) out of orders
...
2. uk.mirror.nekoware.net (Stuart)
...


Sorry about that... we've just moved offices, and the machine has been powered off since just before Christmas, and happens to be the default server in the default nekosync.conf file! It's now back on, though, so everything should be okay...

joerg wrote: The main mirror doesnt sync anymore since middle august. I already send a mail to Dexter but didnt get any responce yet. The biggest problem is that all others sync against Dexters machine.


uk.mirror.nekoware.net currently syncs from rsync://rsync.nekochan.net/nekoware and so should be current (although having said this, it'll be getting back in sync for the next few hours as it's only just been turned back on, so please don't all hit it at once :) )

Update : All up to date now - sync away!
Just a quick heads-up: The nekoware build of gimp fails with the beta build of gtk :

Code: Select all

72863:gimp: rld: Fatal Error: attempted access to unresolvable symbol in /usr/nekoware/lib/libgtk-x11-2.0.so.1: pango_language_get_default

... and additionally pygtk is built against python-2.4, meaning that gimp doesn't work properly with the only python currently available in Nekoware :(

The latter problem can be solved by upgrading pygtk against the current python package, but I suspect that the former will require a rebuild of gimp.
Running swmgr against the entire Nekoware repository results in the following dependencies problem:

neko_dia.sw.eoe requires neko_perl.modules.xml_parser - which doesn't exist. neko_perl_xml_parser.sw.eoe , however, does.
... now a viable alternative to NetBSD's pkgsrc.


Despite the effort I've put into using and improving NetBSD's pkgsrc on IRIX over the past 18+ months, I've finally decided to abandon and remove it. It is just too time-consuming to maintain, for two main reasons:

  • The build process is in some ways very basic, and can only handle package upgrades by compiling the new package, then recursively removing all dependencies, then installing the updated package, and then rebuilding all of the packages just removed. This is fine if time-consuming, so long as one of the dependent packages isn't something critical such as libiconv or bash (as the build-system is based around shell-scripts). Given that many builds need tweaks to build correctly on IRIX (and that the Makefile-based packaging system doesn't lend itself to significant modifications of package build processes) this can result in time consuming manual-rebuild of pretty much the entire installation for the sake of one new package;
  • Although I'm sure that developers are making their best efforts, IRIX is very much a minority platform and is definitely suffering from bit-rot. Sadly, many of the packages for which I submitted bugs reports or patches in the distant past are still broken today in the same ways. Generally, the level of interaction with developers is low, and the lack of a readily accessible bug-tracker (pkgsrc' bug-tracking is mailing-list based) is unhelpful.

This has leads me to spend less time maintaining my pkgsrc installations, to the point where a large number of pacakges which won't build out of the box are now in various states of installation or uninstallation, and are in need of an upgrade. I've decided that I can no longer afford the time it would take to fix this.

The main reason for this change of heart is that, after a number of months of work, I now have a portage installation running on a couple of different machines - and it works brilliantly.

(Indeed, the only weird problem is that Xchat works perfectly on my Fuel but crashes whenever any menu item is selected on my Octane, when built from the same source with the same options)

Furthermore, Gentoo ebuilds are easy to modify, it's easy to create overlay repositories for modified packages, and the developers on bugs.gentoo.org are, in general, very responsive!

All that's needed is an IRIX machine with at least 1.5Gb of free disc space, root access only in order to create a dedicated user, and the MIPSpro compiler suite. I have written a custom compiler wrapper (to fix common GNUisms related to compiler-invocation) which is targeted at MIPSpro 7.4.4m, so with previous versions YMMV.

Whilst it should ultimately be possible to package all that's needed to get started into a single unpack-and-run tar archive suitable for any system, there are probably caveats that I've not yet thought of or encountered... so at this stage I've like to ask anyone who thinks they might be interested to PM or email me, and I'll walk you through the initial stages of installation individually.

The Gentoo Prefix project supports running portage on Mac OS X, NetBSD (ironially ;), OpenBSD, Solaris, AIX, HPUX - and there's a fair amount of momentum behind it. Please support Gentoo on IRIX, and help keep this platform relevant for just that little bit longer! :)

(P.S. If anyone's interested in an archive of all the changes and patches I've written for pkgsrc packages then please let me know - I'll likely be erasing these at some point.)

_________________
:1600SW: :O2: :Octane2: :Octane2: :Fuel: :O200:
http://irix-tools.homeunix.net/
Hi Chris,

Here's the archive of scripts I wrote and package-level fixes... although many of these may now be outdated. I believe that I also had to hack some of the core .mk files too - but I don't remember which ones or how. Make of this what you will...

Best of luck,

stuart

_________________
:1600SW: :O2: :Octane2: :Octane2: :Fuel: :O200:
http://irix-tools.homeunix.net/
Prefix Portage Installation Guide for IRIX

Firstly, you need to decide where your prefix installation will be located: I'd suggest '/opt/gentoo/' (the more obvious '/opt/portage/' looks a little odd for paths such as '/opt/portage/usr/portage/...').

Create this directory, and subdirectory named 'home' within it. Create the user and group 'portage:portage' with UID and GID 250 with the recently-created 'home' directory as their home directory, and then recursively change ownership of the top-level installation directory to 'portage:portage'.

Save the following script as '~portage/.bashrc', altering EPREFIX as necessary:

Code:
EPREFIX="/opt/gentoo"

CHOST="mips-sgi-irix6.5"

PATH="${EPREFIX}/sbin:${EPREFIX}/usr/sbin:\
${EPREFIX}/usr/${CHOST}/bin:\
${EPREFIX}/usr/bin:${EPREFIX}/bin:\
/opt/bin:/usr/local/bin:\
/usr/nekoware/bin:/usr/bsd/bin:\
/usr/nekoware/sbin:/usr/bsd/sbin:$PATH"
export PATH EPREFIX CHOST

LD_LIBRARYN32_PATH="${EPREFIX}/usr/lib:${EPREFIX}/lib:${EPREFIX}/usr/lib/nspr"
export LD_LIBRARYN32_PATH

# This breaks most builds...
#ac_cv_path_RAWCPP="$( which cpp )"
CC="cc"
BUILD_CC="cc"
CXX="CC"
CXXCPP="CC -E"
export CC BUILD_CC CXX CXXCPP # ac_cv_path_RAWCPP

MIPSPRO_DEBUG=0
MIPSPRO_VERBOSE=0
MIPSPRO_PERMISSIVE=0
export MIPSPRO_DEBUG MIPSPRO_VERBOSE MIPSPRO_PERMISSIVE

# This should now all be handled by the IRIX MIPSpro wrapper...
# ... but some builds (such as perl) interrogate these flags directly without
# going via the compiler, so we do need to define them in the environment
# regardless.

common="-O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2"

# cc-1035 is generated when the compiler hits '#error', but by default it
# is treated only as a warning.  This is broken.
common="$common -diag_error 1035"

# There are various problems building C++ code with MIPSpro 7.4.4m compiler
# front-end, which can actually produce incorrect code.  This can be worked-
# around by using the 7.4.3m front-end, which appears not to be affected.
fixcxx="-LANG:std=off:libc_in_namespace_std=off -Zf,_245"

# Comment out the following line to increase C++ compatibility...
unset fixcxx

bsdcompat="-D_BSD_COMPAT"
bsdfull="-D_BSD_TYPES -D_BSD_TIME" # -D_BSD_SIGNALS : Breaks use of <sigaction.h>

quiet="-woff 1174,1183,1185,1552"
ccquiet="${quiet},3968,3970"
# With `-Zf,_245', the higher error numbers aren't set...
if [ -n "$( echo "${fixcxx}" | grep "_245" )" ]; then
cxxquiet="${quiet}"
else
cxxquiet="${ccquiet}"
fi

nowarn="-woff 1009,1014,1110,1116,1188,1204,1230,1233 -Wl,-woff,84,-woff,85"

# Additional options:
# -signed   Make variables of type 'char' default to 'signed char' rather than
#           'unsigned char'
#

CPPFLAGS="${BSDCOMPAT} -I${EPREFIX}/usr/include"
CFLAGS="-c99 ${common} ${ccquiet}"
CXXFLAGS="-J2 ${common} -FE:eliminate_duplicate_inline_copies:template_in_elf_section ${cxxquiet} ${fixcxx}"
LDFLAGS="-Wl,-s,-x,-n32,-mips4,-rdata_shared,-allow_jump_at_eop" # -v
LDFLAGS="${LDFLAGS},-rpath,${EPREFIX}/usr/lib:${EPREFIX}/lib -L${EPREFIX}/usr/lib -L${EPREFIX}/lib"

unset common fixcxx bsdcompat bsdfull quiet ccquiet cxxquiet nowarn
export CPPFLAGS CFLAGS CXXFLAGS LDFLAGS

# Other random fixes...
CONFIG_SHELL="$( which bash )"
export CONFIG_SHELL

gentoopath="${EPREFIX}/usr/share/man:${EPREFIX}/usr/man"
sysman="/usr/catman:/usr/share/man:/usr/share/catman"
optman="/opt/man:/opt/modules/2.2.2.5/man"
sgiman="/usr/freeware/catman:/var/sgi_apache/server/man"
localman="/usr/local/man"
bsdman="/usr/bsd/catman:/usr/bsd/man:/usr/bsd/lib/perl5/man:/usr/bsd/lib/perl5/site_perl/man:/usr/bsd/lib/perl5/vendor_perl/man"
nekoman="/usr/nekoware/man:/usr/nekoware/ssl/man"
MANPATH="$gentoopath:$sysman:$optman:$sgiman:$localman:$bsdman:$nekoman"
#MANFMTCMD="groff -Tascii -man"

export MANPATH # MANFMTCMD
unset gentoopath sysman optman sgiman localman bsdman nekoman

# The 'rs', 'hl' and 'ca' directives don't work as of coreutils-7.1
type -pf dircolors >/dev/null && eval $( dircolors -b | sed 's/rs=[^:]\+:// ; s/:hl=[^:]\+:/:/ ; s/:ca=[^:]\+:/:/' )
alias ls='ls --color=auto -hF'
alias grep='grep --colour'
alias man='PAGER="less" man'

EDITOR="vim"

export EDITOR

XDG_DATA_HOME=/opt/gentoo/usr/share
XDG_DATA_DIRS=/opt/gentoo/usr/share

export XDG_DATA_HOME XDG_DATA_DIRS

# set vi:nowrap

Finally, download the bootstrap script from http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/scripts/bootstrap-prefix.sh?format=txt and the compiler wrapper from http://files.irix-tools.homeunix.net/irix/IRIX-MIPSpro-wrapper.tar.bz2 .

Become your portage user, copy the bootstrap script to your home directory, and extract the IRIX-MIPSpro-wrapper archive to your installation root directory (e.g. 'tar -xjvf IRIX=MIPSpro-wrapper.tar.bz2 -C /opt/gentoo/'). Finally run 'hash -r', and from now on you should be using the compiler wrappers. These are controlled by the MIPSPRO_ * variables - MIPSPRO_VERBOSE=1 will result in copious output regarding what the wrapper is doing, and MIPSPRO_DEBUG=1 will show additional debugging information. Additional options are MIPSPRO_WRAPPER (set to 0 to disable the wrapper entirely, which is highly unrecommended!), MIPSPRO_ALLOWNOSTD (to allow -nostdlib and -nostdinc, which generally break builds: default off), MIPSPRO_MANGLE (to add additional optimisations beyond simply setting library paths: default on), MIPSPRO_INJECT (experimental fix for use of GNU __attribute__s: default off), MIPSPRO_PERMISSIVE (to pass unrecognised options to the compiler even though they're likely GNUisms: default on for now), and MIPSPRO_ABORT (when MIPSPRO_PERMISSIVE is set to 0, the wrapper exits with a failure if an unrecognised option is encountered, rather than silently dropping it: default off).

By default, the wrapper will auto-detect your platform (e.g. "IP30") and CPU (e.g. "r14000"). Other optimisation options default to '-mips4', '-n32', and '-O2' with an Olimit of 8192. These can be overridden with MIPSPRO_ISA, MIPSPRO_ABI, OLIMIT, and MIPSPRO_OPT.

As per the Solaris and Mac OS installation guides, as your portage user now run:

Code:
$ chmod 755 bootstrap-prefix.sh
$ STDPATH="$PATH"
$ export PATH="$EPREFIX/tmp/usr/bin:$EPREFIX/tmp/bin:$PATH"
$ ./bootstrap-prefix.sh $EPREFIX tree

At this point, you may need to apply the flag-o-matic patch from the note at the bottom of this post. In any case, proceed with:

Code:
$ ./bootstrap-prefix.sh $EPREFIX/tmp make
$ ./bootstrap-prefix.sh $EPREFIX/tmp wget
$ ./bootstrap-prefix.sh $EPREFIX/tmp sed
$ ./bootstrap-prefix.sh $EPREFIX/tmp python
$ ./bootstrap-prefix.sh $EPREFIX/tmp coreutils6
$ ./bootstrap-prefix.sh $EPREFIX/tmp findutils
$ ./bootstrap-prefix.sh $EPREFIX/tmp tar15
$ ./bootstrap-prefix.sh $EPREFIX/tmp patch9
$ ./bootstrap-prefix.sh $EPREFIX/tmp grep
$ ./bootstrap-prefix.sh $EPREFIX/tmp gawk
$ ./bootstrap-prefix.sh $EPREFIX/tmp bash
$ ./bootstrap-prefix.sh $EPREFIX portage
$ hash -r
$ USE="-*" emerge --oneshot -v --keep-going sed wget bash baselayout-prefix lzma-utils m4 flex bison coreutils findutils tar grep patch gawk make
$ USE="-*" emerge --oneshot -v --nodeps file
$ FEATURES="-collision-protect" emerge -v --oneshot portage
$ export PATH="$STDPATH"
$ unset STDPATH
$ hash -r
$ rm -r $EPREFIX/tmp/*
$ emerge --sync
$ emerge -uv system
$ emerge -Dev --with-bdeps y system

... which should result in a minimal but working and fully-installed system!

You can now use this as any user by adding "/opt/portage/usr/bin:/opt/portage/bin" to their PATH.

Please note

This initial installation stage may be fragile, or may run into unforeseen problems. Please expect this, but also please don't be disheartened. Simply post any problems here or IM me, and we can sort it out. This setup has worked for me on a couple of different machines, but hasn't received any wider testing. Only mips4 n32 code on R10k+ processors has been tested - o32 may be slighly more compatible with legacy code which resides within certain source-trees still (such as _ctypes/FFI support in Python), whilst 64bit support is untried.

I have pre-built stages available for IP30/R12k, IP30/R14k, and IP35/R14k - although above R10k, the binaries will run happily on any CPU. I plan to assemble and upload these shortly.

There is a file installed to $EPREFIX/home/patches/flag-o-matic.eclass.patch which should be applied (with 'patch -p0') after every sync - without this, builds using "append-flags -L" (notably Python) will fail.

_________________
:1600SW: :O2: :Octane2: :Octane2: :Fuel: :O200:
http://irix-tools.homeunix.net/
bash-3.2 and bash-4.0 should both work on IRIX, so long as they are not compiled above '-O1' (at which points MIPSpro optimisations break it quite badly). This should all be dealt with by the ebuild, though.

What might be happening here is that a recent 'portage' update changed the ebuild semantics from requiring 'EAPI="prefix"' to breaking with a similar error if that directive is present.

If this is the cause of the problem, then either re-syncing portage (from the already-installed binaries) with 'emerge --sync' and/or re-installing the latest portage if the necessary dependencies are present ('USE="-*" FEATURES="-test" emerge --oneshot -v portage') should fix the problem.

(Or, alternatively, the overlay packages I included may now be out of date - try re-downloading http://files.irix-tools.homeunix.net/irix/IRIX-MIPSpro-wrapper.tar.bz2 , which I have just updated, or run 'PORTDIR_OVERLAY="" emerge --oneshot -v =perl-5.8.8-r5' and please let me know if either works)

_________________
:1600SW: :O2: :Octane2: :Octane2: :Fuel: :O200:
http://irix-tools.homeunix.net/
This sounds like a bug - it happens occasionally... it's worth reporting this at bugs.gentoo.org.

In the meantime, you can edit the ebuilds directly and remove references to the missing packages.

_________________
:1600SW: :O2: :Octane2: :Octane2: :Fuel: :O200:
http://irix-tools.homeunix.net/
When I try to start the latest firefox, I get:

Code:
$ firefox
116578123:/usr/nekoware/lib/firefox-2.0.0.22pre/firefox-bin: rld: Fatal Error: attempted access to unresolvable symbol in /usr/nekoware/lib/firefox-2.0.0.22pre/firefox-bin: sqlite3_enable_shared_cache


... and:

Code:
$ ldd /usr/nekoware/lib/firefox-2.0.0.22pre/firefox-bin
libm.so  =>      /lib32/libm.so
116541784: 17:12:57 /usr/nekoware/lib/firefox-2.0.0.22pre/firefox-bin: rld: Fatal Error exit/longjmp: Cannot Successfully map soname 'libsmime3.so' under any of the filenames ../../dist/bin/libsmime3.so:/usr/nekoware/lib/libsmime3.so:/lib32/libsmime3.so:/usr/lib32/libsmime3.so:/usr/lib32/internal/libsmime3.so:/opt/lib32/libsmime3.so:
116541784:/usr/nekoware/lib/firefox-2.0.0.22pre/firefox-bin: rld: Fatal Error: Cannot Successfully map soname 'libsmime3.so' under any of the filenames ../../dist/bin/libsmime3.so:/usr/nekoware/lib/libsmime3.so:/lib32/libsmime3.so:/usr/lib32/libsmime3.so:/usr/lib32/internal/libsmime3.so:/opt/lib32/libsmime3.so:


... now I'm not sure that the first error exactly aligns with the second (since the warning is of an unresolvable symbol rather than a missing library, and the firefox script sets its own LD_LIBRARY*PATH variables).

Infact, with LD_LIBRARYN32_PATH set to "/lib32:/usr/lib32:/usr/nekoware/lib/firefox-2.0.0.22pre", and with 'ldd' reporting:

Code:
$ ldd firefox-bin
libm.so  =>      /lib32/libm.so
libsmime3.so  =>         /usr/nekoware/lib/firefox-2.0.0.22pre/libsmime3.so
libssl3.so  =>   /usr/nekoware/lib/firefox-2.0.0.22pre/libssl3.so
libnss3.so  =>   /usr/nekoware/lib/firefox-2.0.0.22pre/libnss3.so
libnssutil3.so  =>       /usr/nekoware/lib/firefox-2.0.0.22pre/libnssutil3.so
libsoftokn3.so  =>       /usr/nekoware/lib/firefox-2.0.0.22pre/libsoftokn3.so
libXt.so  =>     /usr/lib32/libXt.so
libsqlite3.so  =>        /usr/nekoware/lib/libsqlite3.so
libxpcom_compat.so  =>   /usr/nekoware/lib/firefox-2.0.0.22pre/libxpcom_compat.so
libmozjs.so  =>  /usr/nekoware/lib/firefox-2.0.0.22pre/libmozjs.so
libxpcom.so  =>  /usr/nekoware/lib/firefox-2.0.0.22pre/libxpcom.so
libxpcom_core.so  =>     /usr/nekoware/lib/firefox-2.0.0.22pre/libxpcom_core.so
libplds4.so  =>  /usr/nekoware/lib/firefox-2.0.0.22pre/libplds4.so
libplc4.so  =>   /usr/nekoware/lib/firefox-2.0.0.22pre/libplc4.so
libnspr4.so  =>  /usr/nekoware/lib/firefox-2.0.0.22pre/libnspr4.so
libpthread.so  =>        /usr/lib32/libpthread.so
libdl.so  =>     /usr/lib32/libdl.so
libgtk-1.2.so.1  =>      /usr/nekoware/lib/libgtk-1.2.so.1
libgdk-1.2.so.1  =>      /usr/nekoware/lib/libgdk-1.2.so.1
libgmodule-1.2.so.1  =>  /usr/nekoware/lib/libgmodule-1.2.so.1
libglib-1.2.so.1  =>     /usr/nekoware/lib/libglib-1.2.so.1
libintl.so.9  =>         /usr/nekoware/lib/libintl.so.9
libXext.so  =>   /usr/lib32/libXext.so
libX11.so.1  =>  /usr/lib32/libX11.so.1
libsocket.so  =>         /usr/lib32/libsocket.so
libfastm.so  =>  /usr/lib32/libfastm.so
libCsup.so  =>   /usr/lib32/libCsup.so
libC.so.2  =>    /lib32/libC.so.2
libCio.so.1  =>  /usr/lib32/libCio.so.1
libc.so.1  =>    /lib32/libc.so.1
libgen.so  =>    /lib32/libgen.so       delay-load
libintl.so.4  =>         /usr/nekoware/lib/libintl.so.4
libiconv.so.3  =>        /usr/nekoware/lib/libiconv.so.3


... I still get:

Code:
$ ./firefox-bin
116579149:./firefox-bin: rld: Fatal Error: attempted access to unresolvable symbol in ./firefox-bin: sqlite3_enable_shared_cache


I'm a little rusty... what have I forgotten to do, here?!

_________________
:1600SW: :O2: :Octane2: :Octane2: :Fuel: :O200:
http://irix-tools.homeunix.net/
It's worth mentioning that Thunderbird and Seamonkey do work - and even Firefox works for long enough to bring up the user/account selector... but after an option is selected is when the error occurs.

_________________
:1600SW: :O2: :Octane2: :Octane2: :Fuel: :O200:
http://irix-tools.homeunix.net/
nekonoko wrote: Looks like you're picking up an older version of libsqlite3.so (which lacks the symbol) from /usr/nekoware/lib rather than the bundled version. From your post above:

Code: Select all

libsqlite3.so  =>        /usr/nekoware/lib/libsqlite3.so


It should be using the libsqlite3.so from /usr/nekoware/lib/firefox-2.0.22pre.


Ah...

Code: Select all

$ showfiles neko_sqlite3.sw.lib
f 51156 1035268 neko_sqlite3.sw.lib   m usr/nekoware/lib/libsqlite3.a
f 43620   850 neko_sqlite3.sw.lib   m usr/nekoware/lib/libsqlite3.la
l     0     0 neko_sqlite3.sw.lib   m usr/nekoware/lib/libsqlite3.so
l     0     0 neko_sqlite3.sw.lib   m usr/nekoware/lib/libsqlite3.so.1
f 10472 463796 neko_sqlite3.sw.lib   m usr/nekoware/lib/libsqlite3.so.1.6
f  2537   260 neko_sqlite3.sw.lib   m usr/nekoware/lib/pkgconfig/sqlite3.pc


I installed neko_sqlite3 recently after a check to see what (if any) libraries were missing, and /usr/nekoware/lib/python2.5/lib-dynload/_sqlite3.so has a dependency on /usr/nekoware/lib/libsqlite.so.1.