The collected works of ShadeOfBlue - Page 3

I've downloaded the Wacom drivers from Nekochan FTP and installed them on my Fuel (running IRIX 6.5.30) as instructed in the README file, but there's a problem ...

It appears the installation was incomplete, there are files missing -- most notably, autoconfig complains it can't find /var/sysgen/master.d/wacomio and /var/sysgen/master.d/wacomxl. Also, the /usr/wacom directory is full of empty subdirectories :(

Here's a screenshot of how the installed package looks in swmgr:
swmgr-wacom.png
swmgr-wacom.png (7.7 KiB) Viewed 343 times

This looks weird to me :?

I've re-downloaded the archive at least 3 times now, from 2 different sources (Nekochan FTP and Ian's Depot), but the effect is still the same.

Could the archive be damaged somehow?
If that is the case, could someone please post a working version here?
I get the same contents. Notice how the dist/WacomTablet.DeviceDriver file is only about 5MB in size, whereas swmgr reports that the "Driver Modules" package uses 13.5MB.
It's possible that it compresses really well, but that doesn't explain why the /usr/wacom directory is only 68kB (empty subfolders and install/uninstall scripts) instead of 13MB+ :?

Meanwhile, I will look through my backups to see if I have any drivers there.
The archive is OK, I've found what the problem is :D

Wacom's install scripts use the 'install' binary, but they forgot to use its full path (/etc/install), so the system picks up the GNU 'install' from Nekoware and it doesn't work due to some differences in arguments.
They don't check if the software was actually installed and the cleanup script cleans the /usr/wacom directory (which explains why it's empty apart from the uninstall scripts).

I will now manually fix the scripts and it should work :)
The installation scripts delete themselves after they finish :?

An easier way would be to temporarily change the PATH environment variable so that "/sbin:/etc" comes before "/usr/nekoware/bin", e.g.:

Code: Select all

# setenv PATH "/usr/sbin:/usr/bsd:/sbin:/usr/bin:/etc:/usr/etc:/usr/bin/X11:/usr/nekoware/bin"
# ./INSTALL_WACOM


This should also work :)
eMGee wrote: I wonder if it's an IRIX 6.5.30 specific issue, because under .26 and .28 I never had the problem.


It's an issue with the order of directories in the PATH variable -- if /usr/nekoware/bin comes before /sbin or /etc, then the system will pick up the wrong 'install' binary (the GNU one instead of the one supplied with the system). This happens regardless of which version of IRIX is installed.

The installation process is weird, though. It installs a tar file via swmgr, unpacks it and runs the install scripts, which do the actual installing. Why they didn't do it the proper way (i.e. installing files directly via swmgr) is beyond me :)
It probably made maintenance easier for all the platforms they used to support.

Anyhow, everything works perfectly now :)
http://forums.nekochan.net/viewtopic.php?f=16&t=10898&hilit=bigvideoin :)
Just an idea... Would it perhaps be easier if there was a separate subforum for nekoware packages?

The package submitter would create a new thread for each submitted package and add a simple "Works: yes/no" poll to the thread. The users could anonymously vote whether the package works for them or not.

Any problems with that package could be reported in the same thread. If enough users vote that the package works, it's moved to /current.
jan-jaap wrote:
Is there a list of key combinations somewhere? I was kind of shocked to see there was no Backspace, PgUp/Down, ... :shock: I've discovered some combinations like Fn-Delete, Option-Up/Down now, but a comprehensive list would be nice.


Here's a nice list: http://guides.macrumors.com/Keyboard_shortcuts :)
The original fan can move 80 m^3/h, but this one moves only 66% as much. The O2's PSU also adjusts the voltage of the fan according to the temperature, so it probably won't run the new fan at full speed because it's calibrated for the old one. [IIRC, there's a potentiometer inside the PSU to adjust this.]

The best way to see if it provides proper cooling would be to get a few of those cheap $2 thermometers from eBay, attach the sensors to various chips inside the O2 (CPU, CRIME, MACE, GBE), run the O2 for a few hours at full load and write down the temperatures, then replacing the fan and repeating the process.
Anything over 70°C is probably very unhealthy.
Perhaps a capacitor in the MLA is about to die?
Open it and check if any of the capacitors on the board have any bulges or leaks.

Code: Select all

typedef unsigned int ui;

ui __[]={
10,9,32,123,33,1,34,16,39,24,42,1,44,4,46,24,47,6,58,1,
66,1,72,1,78,1,79,1,83,1,89,1,91,1,92,6,93,1,94,6,95,1,

96,4,       97,3,100,1,    101,     4,102,
1,104,1,108,   1,     112,2,   114,  1,117,1,119,
1,       121,  1,     126,  1,  128, 252,      255,
182,   161,   66,   127, 204,  207,  217,    113,
164,    178, 44,   227,  165,         98,
243,     205,121,   199,  231,        208,
154,      23,88,      7,   61,        36,
195,       150,44,   149,   52,       23,
56,192,42,   252,69,251,     39,     191,203,144,
29,149,148,    6,230,186,      6,    95,139,255,40,

132,2,36,214,120,154,155,159,85,63,18,247,241,143,
254,205,138,235,137,204,189,164,5,30,110,241,149,141,200,
213,207,65,37,134,74,205,22,92,106,111,84,187,217,173,50,0};

#define X(o_o) for(_=o_o^o_o;_<o_o;_++)
#define T (1<<24)
#define B (1<<16)
#define i __[p++]
#define f(t) ((c-l)/(r/=t))

int main(ui _)      {
ui l,
c,r,p=0,
n[129],s,y,
cf; extern int
putchar(int); X(129)
_[n]=_^_; while
(__[p]!=255 && (y=
__[p],1)) y[n]=__[++p],
p++;p++; s=0;X(128)y=_[n],n
[_]=s,s+=y;n[128]=s; l=c=0, r=
(ui)-1; X(4) c=c<<8|i;
X(s) { for (cf=f(s),y=0;
n[y+1]<=cf||(putchar(y),0)
;y++); l+=n[y]*r; r*=n[y+1]-y[n];
while ((l^l+r)<T||r<B&&((r=-l&B-1),1)
)c=c<<8
|i,r<<=
8,l<<=8
;} return 0;
}


Copy the above into a file (e.g. card.c), then:

Code: Select all

$ cc -o card card.c
$ ./card

It works even if you don't have MIPSpro (use /var/sysgen/root/usr/bin/cc) or with other compilers on other OS's (tested with gcc, icc and clang).

:mrgreen:
You could look at the Boehm GC ( http://www.hpl.hp.com/personal/Hans_Boehm/gc/ ) for the stack-specific stuff (it has an IRIX port and thread support). It seems like the firefox guys are reinventing the wheel :)
I bought this a few years ago:
Image

Synchronizes time and date automatically, solar powered, requires no maintenance.
Perhaps I'm just lazy, but I love it :)
tjsgifan wrote: This avoids the problems mentioned above and would stop people incorrectly bad mouthing SGI's tech guy's.

A firmware update should never render a system unbootable.

It wouldn't have been that hard to add a check to the flashsc program to prevent such a situation from occurring, or to actually handle non-incremental updates properly. For a system that used to cost many thousands of dollars, I'd expect them to get at least this right.

But this is hardly the only problem with the 1.44.0 update; the update for the O3000's L2 controller is actually missing a file in the firmware image, breaking a large part of the L2 controller's functionality (including the ability to reflash it to an earlier version) -- how does this even get past testing?

I usually have a lot of respect for SGI engineers, but whoever was responsible for quality assurance on the 1.44.0 update did a bad job.
mapesdhs wrote: The only thing wrong with my setup atm is the Phobos P1000 Gbit NIC in the O2 runs really slow, barely
more than 5 to 10MB/sec. I'm sure there must be kernel stuff one can do to fix it, but so far I've gotten nowhere.


Have you tried enabling jumbo frames ? It really helps , especially on CPU-starved machines.
mapesdhs wrote: Is there some other way of changing the MTU for the pge0 link if this method isn't applicable?

Try editing /var/sysgen/master.d/if_pge if it exists. Some drivers honor the MTU settings in the ifconfig file and some don't, so you have to edit the driver config instead.

There's also a possibility that the Phobos card doesn't support jumbo frames at all.

mapesdhs wrote: I changed snd/recvspace, but performance is still poor, around 32MB/sec. Real ftp speed is much worse, about 14MB/sec for sending
a file from the O2 to my Fuel, and a measly 4MB/sec for receiving a file to the O2 from the Fuel (ftp session running on the O2, 275MB file).

The biggest performance gain comes from jumbo frames, but it's also possible that the driver is poorly written or the card is badly made. You should be able to get at least 50MB/s of raw performance as measured by iperf.
mapesdhs wrote: It does exist, but I'm not sure what I should change that's applicable:

Hmm... OK, so there's nothing in the driver config file and the driver won't honor the ifconfig mtu setting.
Perhaps there's a systune parameter that the driver exports? Look into the /var/sysgen/mtune/if_pge file, the variables listed there (if any) are available for tweaking via systune (you can also edit the file directly, run autoconfig and reboot).

You can also take a look at the card itself, google the part number of its ethernet controller and check the datasheet to see if it supports MTUs bigger than 1500.


mapesdhs wrote:

Code: Select all

write2 failed: Interrupted function call

What do you make of that? Note the Fuel is still using MTU 1500.

That's probably a bug in iperf :D
The write call returned an EINTR, which the program was supposed to handle by repeating the write call, but I guess nobody implemented that. You could try a newer version of iperf to see if it has been fixed.


mapesdhs wrote: So it's much quicker sending data to the Fuel than receiving it. Strange...

These results are really poor for a gigabit card; putting a quad-port (or even dual-port) 100Mbit ethernet card and trunking the ports would give better results :/

You could try tweaking the Phobos_pge_TX_DESC and Phobos_pge_RX_DESC parameters in that master.d file, but I have a feeling that the driver adjusts them automatically.

Oh, you could also increase 'systune maxdmasz' (the value is in pages, so 4kB on an O2, IIRC). I remember the default value is really low, at least for an Origin system.

mapesdhs wrote: Should I set the Fuel's MTU to 9000?

If you do, you should do the same for all other machines on that subnet, otherwise you will get weird errors (e.g. ssh connections will randomly disconnect, chat clients will constantly reconnect, etc.).
I have a separate subnet just for jumbo-frame-capable hardware and haven't had any problems.
A friend of mine also has mixed jumbo- and non-jumbo devices on the same subnet and it works fine for him, but I remember reading that this actually isn't guaranteed to work (it relies on path MTU discovery, which can be flakey), so I decided to play it safe and make a separate subnet :)

If you still have that switch, you can open it and check if a capacitor has blown -- this is the single most common failure in switches and it's easy to replace.
I've received a stack of "dead" 24-port 10/100 switches, which all had a blown capacitor and started working properly after I replaced it.
Thanks for getting everything working again!
crrn wrote: @bvdwiel
Hi
take a look at Pouet.net here http://www.pouet.net/prodlist.php?platf ... e=1&order=

These look interesting, thanks for sharing!
(Also, welcome to the forum :) )
hamei wrote:
It doesn't cost any more to write good code instead of the crap we see, so why ? I'm kind of curious.


Lack of skills. Schools still focus too much on memorization instead of teaching the underlying concepts and often jump on the trendy language of the year. It happens way too often that the students only copy&paste snippets from the web together and change them minimally so it sort of works.
The result is that we have a lot of people who barely know one language (Java and C# seem to be popular these days) and nothing else.

I once overheard a conversation about pointers in C... One student asked another how he knows how many asterisks he has to put in a variable declaration and the other proudly replied that he just keeps adding them until it compiles :lol:
Sadly, they were final-year BSc students.

It also takes time to properly test software, so most people don't bother. This is especially present in various programs people made for their own amusement and later released as open source. (I've been guilty of this as well, e.g. with nekopkg.sh, which started as a quick hack that I meant to rewrite but haven't had the time to do so yet.)

From what I've heard, schools don't encourage their students to enable warnings when compiling or to use static code analyzers. This is really bad, because using these tools helps people become better programmers.

I've noticed that the good programmers invest their own time into learning new things and aren't just concerned with passing the classes and getting a piece of paper.
Such people usually end up with well-paid jobs and they have very little competition. Web development is an entry-level job, which explains why some websites are so poorly made.
Thanks for taking the time to scan all these brochures and magazines :)
A friend sent me this:
Image

You know, it might actually be a good idea for schools to teach programming on old workstations, e.g. the SparcStation IPX, then people would have to think before compiling something :mrgreen:
I don't really see the point of a smaller iPad. If they made a 2x bigger version, now that would be interesting :)
Nicely maxed out O2 :)

I am curious about the temperature of the HDD, could you please post the output of scsimon after the system has been running for about an hour?
Thanks :)
GCC has one of the crappiest build processes ever devised by man, so I made this howto to help people build it as pleasantly as possible.

You will need about 4GB of disk space. It takes about 2.5 hours to build everything on a 16-processor Origin 3400 (8x 500MHz + 8x 400MHz, 16GB of RAM).
Most of that time is spent in "genattrtab", which is _glacially_ slow and should be rewritten. The rest of that time is spent by gmake re-running "configure" for the 2873517th time. There is also some compiling :)

You may skip the "gmake -j16 check" step while building gmp, mpfr, and mpc.

If you are building this on a machine with a different number of processors, replace every "gmake -j16" below with "gmake -j<your_number_of_cpus_here>".

You will need GCC 4.3.2 from Nekoware, or something newer to build this; GCC 3.x won't do. Binutils also need the 'texinfo' package for some reason.


Anyway, let's begin.


0. Make a build directory:
Code:
mkdir build-gcc && cd build-gcc

You can delete this directory after installation is complete.


1. Download prerequisites:
Code:
curl -O ftp://ftp.gmplib.org/pub/gmp-5.0.5/gmp-5.0.5.tar.bz2
curl -O http://ftp.gnu.org/gnu/binutils/binutils-2.18.tar.bz2
curl -O http://www.mpfr.org/mpfr-current/mpfr-3.1.1.tar.bz2
curl -O http://www.multiprecision.org/mpc/download/mpc-1.0.1.tar.gz
curl -O ftp://gcc.gnu.org/pub/gcc/infrastructure/ppl-0.11.tar.gz
curl -O ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.11.tar.gz
curl -O ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.6.3/gcc-4.6.3.tar.bz2



2. Extract packages:

This will take a while, make yourself some coffee :)
Code:
tar jxf gmp-5.0.5.tar.bz2 && tar jxf binutils-2.18.tar.bz2 && tar jxf mpfr-3.1.1.tar.bz2 && tar zxf mpc-1.0.1.tar.gz && tar zxf ppl-0.11.tar.gz && tar zxf cloog-ppl-0.15.11.tar.gz && tar jxf gcc-4.6.3.tar.bz2


You can now delete the archives to save disk space:
Code:
rm *.tar.bz2 *.tar.gz



3. Build gmp:
Code:
cd gmp-5.0.5
./configure --disable-shared --enable-static --prefix=/opt/gcc-4.6.3 --enable-cxx CPPFLAGS=-fexceptions
gmake -j16
gmake -j16 check
sudo gmake install
gmake clean



4. Build mpfr:
Code:
cd ../mpfr-3.1.1
./configure --disable-shared --enable-static --prefix=/opt/gcc-4.6.3 --with-gmp=/opt/gcc-4.6.3
gmake -j16
gmake -j16 check
sudo gmake install
gmake clean



5. Build mpc:
Code:
cd ../mpc-1.0.1
./configure --disable-shared --enable-static --prefix=/opt/gcc-4.6.3 --with-gmp=/opt/gcc-4.6.3 --with-mpfr=/opt/gcc-4.6.3
gmake -j16
gmake -j16 check
sudo gmake install
gmake clean



6. Build PPL:
Code:
cd ../ppl-0.11
./configure --disable-shared --enable-static --prefix=/opt/gcc-4.6.3 --with-gmp-prefix=/opt/gcc-4.6.3 --without-java --disable-watchdog --disable-ppl_lcdd --disable-ppl_lpsol --disable-ppl_pips CPPFLAGS=-fexceptions

The configure script thinks we have support for getopt_long, but we don't. Correct that error manually by editing config.h and src/ppl.hh.dist -- comment out the lines containing "HAVE_GETOPT_H". You also have to delete the line with D["HAVE_GETOPT_H"]=" 1" in config.status .

Code:
gmake -j16
sudo gmake install
sudo gmake clean



7. Build CLooG-PPL:
Code:
cd ../cloog-ppl-0.15.11
./configure --disable-shared --enable-static --prefix=/opt/gcc-4.6.3 --with-gmp=/opt/gcc-4.6.3 --with-ppl=/opt/gcc-4.6.3
gmake -j16
sudo gmake install
gmake clean



8. Build binutils:
Code:
cd .. && mkdir bu-objs && cd bu-objs

../binutils-2.18/configure --prefix=/opt/gcc-4.6.3 --with-gmp=/opt/gcc-4.6.3 --with-mpfr=/opt/gcc-4.6.3 --with-mpc=/opt/gcc-4.6.3 --disable-libssp --disable-nls --disable-werror --without-docdir

gmake -j16
sudo gmake install
gmake clean



9. Build gcc:
Code:
cd .. && mkdir gcc-objs && cd gcc-objs

../gcc-4.6.3/configure --prefix=/opt/gcc-4.6.3 --with-gmp=/opt/gcc-4.6.3 --with-mpfr=/opt/gcc-4.6.3 --with-mpc=/opt/gcc-4.6.3 --with-cloog=/opt/gcc-4.6.3 --with-ppl=/opt/gcc-4.6.3 --with-as=/opt/gcc-4.6.3/bin/as --with-ld=/opt/gcc-4.6.3/bin/ld --with-gnu-as --with-gnu-ld --with-host-libstdcxx=/usr/nekoware/gcc-4.3/lib32/libstdc++.a --disable-libssp --disable-nls --disable-lto --disable-shared --enable-static --enable-threads=posix --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++ --with-arch=mips4 --with-abi=n32

gmake -j16
sudo gmake install


You may now delete the build directory:
Code:
cd ../..
rm -rf build-gcc



10. Free up lots of space:

This reduces the size of the install directory from almost 600MB to 175MB.

Code:
sudo rm -r /opt/gcc-4.6.3/share/doc /opt/gcc-4.6.3/share/aclocal /opt/gcc-4.6.3/share/man/man3 /opt/gcc-4.6.3/share/man/man7 /opt/gcc-4.6.3/share/man/man1/ppl-config.1 /opt/gcc-4.6.3/share/info /opt/gcc-4.6.3/info /opt/gcc-4.6.3/lib/*.{a,la} /opt/gcc-4.6.3/bin/ppl-config

sudo strip -s /opt/gcc-4.6.3/bin/* /opt/gcc-4.6.3/mips-sgi-irix6.5/bin/* /opt/gcc-4.6.3/libexec/gcc/mips-sgi-irix6.5/4.6.3/* /opt/gcc-4.6.3/libexec/gcc/mips-sgi-irix6.5/4.6.3/install-tools/fixincl



That's all, folks :)
PymbleSoftware wrote:
The wiki has a How To section.

I know, but this is just an intermediary step. My original goal was to compile 4.7.2 and I intend to post the howto for that on the wiki (as well as here) when it's finished.
canavan wrote:
If you're compiling 4.7.? anyway, could you please make nekoware packages?

I could probably find the time to do that next weekend, however, the 4.7.2 compile isn't looking too good at the moment.

This happens during stage1, while gcc 4.7.2 is building libstdc++ with itself (xgcc):
Code:
../../../../gcc-4.7.2/libstdc++-v3/libsupc++/vec.cc: In function 'void __cxxabiv1::__cxa_vec_delete2(void*, std::size_t, std::size_t, __cxxabiv1::__cxa_cdtor_type, void (*)(void*))':
../../../../gcc-4.7.2/libstdc++-v3/libsupc++/vec.cc:323:3: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2231
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
gmake[5]: *** [vec.lo] Error 1


I can work around that by opening ../gcc-4.7.2/libstdc++-v3/libsupc++/vec.cc and changing lines 292 and 325 to:
Code:
extern "C" void __attribute__((optimize("O1")))

(this lowers the optimization level for those functions to -O1 from the default -O2), but then the same error happens in ../gcc-4.7.2/libstdc++-v3/src/c++98/strstream.cc (in the function starting at line 320) and then again in a generated header somewhere in the build directory ...

GCC was configured as follows:
Code:
../gcc-4.7.2/configure --prefix=/opt/gcc-4.7.2 --with-gmp=/opt/gcc-4.7.2 --with-mpfr=/opt/gcc-4.7.2 --with-mpc=/opt/gcc-4.7.2 --with-cloog=/opt/gcc-4.7.2 --with-ppl=/opt/gcc-4.7.2 --with-as=/opt/gcc-4.7.2/bin/as --with-ld=/opt/gcc-4.7.2/bin/ld --with-gnu-as --with-gnu-ld --with-host-libstdcxx=/opt/gcc-4.6.3/lib32/libstdc++.a --disable-libssp --disable-nls --disable-lto --disable-shared --enable-static --enable-threads=posix --enable-libgomp --enable-obsolete --enable-languages=c,c++,fortran,objc,obj-c++ --with-arch=mips4 --with-abi=n32

The prerequisites have been configured as written in the howto above, except with the prefix set to /opt/gcc-4.7.2.

Conclusion:
The optimizer in GCC 4.7.2 is broken at -O2, so there's not much I can do to fix this.
Even if I were to manually change the optimization level for each function this error appears in (or force -O1 for the entire libstdc++), the finished compiler would probably have the same problem and would therefore be useless for any practical work :(

I will try building the SVN version either tomorrow or on Saturday, but I don't have high expectations for this one ...
Thanks for the tips, jan-jaap!

I omitted Ada and Java on purpose, since I have no use for them :)
I can build the Java frontend if anyone needs it for the Nekoware package (but please let me know before Saturday).

GNU ld from 2.18 seems to be working for simple things, but you're right, I should have run the testsuite.

You mentioned that 4.7.0 works OK, so I will try building 4.7.1 now.
4.7.2 crashes with the error in my previous post, which looks unrelated to binutils.

I also noticed that GCC on IRIX has been obsoleted, this is bad. There was a thread on this a while ago and I got the impression that someone provided the testing hardware, so that this wouldn't happen. Did something go wrong with that?

A few gotchas I've encountered, in case someone else reads this and wants to try doing things differently:
  • the in-tree build (i.e. building gcc and all its prerequisites from the gcc directory) is broken
  • latest binutils are broken -- programs segfault immediately (though it might only be ld's fault)
  • you must use the exact versions of ppl and cloog-ppl mentioned above, newer versions won't work
  • the documentation on GCC's website is for the SVN version (download the package and read the docs in there, the prerequisites are very different)

There's probably more, but this is all I can remember at the moment.
4.7.1 is currently compiling and it looks good so far (it got much further than 4.7.2 before) :)

jan-jaap wrote:
There are many intricacies to building a compiler toolchain. As you found out, GCC has many dependencies. If you build the dependencies (or binutils with shared BFD) with GCC, they will depend on libgcc_s.so, creating a circular dependency. A misconfigured compiler can thus leave you without functional toolchain suitable of recovering. I maintain a separate 'bootstrap' compiler outside $PATH with all dependencies linked in statically to avoid this, and, in general, build any DSOs with MIPSpro to avoid libgcc_s.so.

I've built all dependencies with "--disable-shared --enable-static" (gcc as well) to avoid such problems.

The final Nekoware package will also have the dependencies linked in statically, since GCC is way too sensitive about certain library versions (ppl and cloog-ppl) and I think a few MB of disk space are a reasonable tradeoff for having things just work :)

Quote:
IRIX obsoletion has been postponed a couple of times but in the end there just weren't enough people to fix bugs and run regression tests on a regular basis. It will be a while before software requires GCC >= 4.8

Oh well.


EDIT: Build successful :D

There seems to be a problem with OpenMP, though, omp_get_num_procs() always returns 1, which is wrong. Setting the number of threads manually with omp_set_num_threads() or OMP_NUM_THREADS works as it should.

OK, so my schedule for next weekend is:
  • see if I can fix the number of CPUs detection code in libgomp
  • build latest binutils again
  • build 4.7.1 and its prereqs with the 4.7.1 that I built today
  • run the testsuite
  • write another howto
  • make a Nekoware package

If somebody needs the Java frontend, please let me know by Saturday, or I will build the package without Java support.
A short update:

4.7.1 with latest binutils (minus ld) compiles OK, it's currently running the testsuite with no failed tests so far.
I didn't touch the OpenMP bug, since it's not in libgomp and I didn't feel like going through gcc's spaghetti code to search for it. The workaround is to just set OMP_NUM_THREADS environment variable to the number of CPUs your machine has before running your OpenMP programs (you can do this in your shell's .profile).

Tomorrow I'll try to find the time to make a Nekoware package. Since this will be my first package, any tips are welcome :)
Thanks, but the forum says "The selected attachment does not exist anymore." for the .tar with your scripts :(

However, I played around with swpkg a bit and it looks fairly straightforward. I've added all the files and set everything up.
It's a bit easier in this case, since everything is contained in a single directory and there are no external dependencies because all prerequisites are linked in statically (gcc needs a really old version of ppl and would break if you upgraded it, so it makes more sense to link it in statically -- I did the same for the other prerequisites, as upgrading them could have the same effect).
I didn't separate the files into .eoe, .lib, and .hdr subsystems, since they depend on each other and installing them separately would make no sense; the current gcc package does the same.

The Origin will have to be powered down now, so I'm going to interrupt the testsuite and continue the objc* tests next weekend. Then I will include the test results in the release notes, make the final package, and test it on a few other machines.
hamei wrote:
Graphics Magick has the same problem, Bob Friesenhahn (sp ?) might have some input on that. Also tripped over this while looking for something else, don't know if there are any clues hidden in there but ...

http://www.cfd-online.com/Forums/openfo ... -irix.html

That one is for MPI, which is a different library :)

This only affects OpenMP programs built with GCC, MIPSpro-compiled ones work as they should.

I've looked at libgomp again and found the error ... It's in libgomp/config/posix/proc.c.
On IRIX, _SC_NPROCESSORS_ONLN is called _SC_NPROC_ONLN. It's a really easy fix, don't know how I missed that earlier :oops:

I'll rebuild gcc and rerun all the tests next weekend.

If only their antiquated testing framework executed the tests in parallel ... It's not 1960 anymore :roll:
A little update:

I've patched libgomp to properly detect the number of CPUs in the machine. The libgomp testsuite passes without any errors and my OpenMP programs also work as they should :)

Here's the patch:
Code:
diff -urnp libgomp-orig/config/posix/proc.c libgomp/config/posix/proc.c
*** libgomp-orig/config/posix/proc.c    Sat Dec  8 14:57:52 2012
--- libgomp/config/posix/proc.c Sat Dec  8 14:58:43 2012
***************
*** 38,43 ****
--- 38,48 ----
#endif


+ #ifdef __sgi
+ #define _SC_NPROCESSORS_ONLN _SC_NPROC_ONLN
+ #endif
+
+
/* At startup, determine the default number of threads.  It would seem
this should be related to the number of cpus online.  */



I hope that the comment below my fix is a joke :)

The rest of the testsuite is running now, but it's so damn slow, I'll probably have to continue it next week.
I've finally found the time to finish the gcc testsuite and uploaded neko_gcc47-4.7.1.tardist into /incoming on the Nekochan FTP server. File size is 97157120 bytes, MD5 checksum is f85d52fbc9eae1fe0be016f28faa55a1.

When it becomes available in the beta directory, please take a look at it, as it is my first Nekoware package :)
If anything looks weird, please comment so that any future packages I submit can be better.
In case anyone has missed it, the finished package has been in /beta for about two weeks now: http://forums.nekochan.net/viewtopic.php?f=15&t=16727285 :)
hamei wrote:
I'd love to check it out Shade , and thanks very much for creating this ... but if I had two compilers on my system I'd really screw up ! :oops:

This one installs under a separate directory (/usr/nekoware/gcc-4.7) and is completely self-contained. Nothing looks in that directory by default, so as long as you don't add it to your PATH, nothing bad should happen :)
Whenever you want to compile something with gcc, just append "CC=/usr/nekoware/gcc-4.7/bin/gcc CXX=/usr/nekoware/gcc-4.7/bin/g++" to the end of the configure command line and it should work.

The previous Nekoware gcc package (4.3) required setting LD_LIBRARYN32_PATH, but this one doesn't, since I've linked everything statically (it's a better choice in this case).
It should Just Work(tm) :mrgreen:

hamei wrote:
I was thinking tho ... how much of the problem with compiling Fireflop is gcc-isms ? Would a gcc version be feasible ?

I've never tried compiling Firefox, but I guess you could give it a shot. A gcc-compiled Firefox is still better than no Firefox at all :)
The reason I linked the prerequisites statically is that GCC is really touchy about their versions.
For example, it needs PPL 0.11, which is an ancient version (newest is 1.0), and CLooG-PPL 0.15.11 (also old). If you use newer versions, it won't work.

If I had created separate packages for such prerequisites and linked them dynamically, those packages could never be updated to newer versions because GCC would break. Maintaining obsolete versions just for GCC would be silly and this is why I linked them statically :)
A common point of failure in O2 CD/DVD drives is a small plastic gear inside, it will crack from too much stress and cause similar behaviour to what you're seeing.
It's easy to fix, though. Simply remove the drive from the O2, open it, locate the broken gear, remove it, glue it together, and put it back in.