What I've been up to

onre

SYS 64738
Feb 8, 2019
121
56
28
Toijala, Finland
@praetor sure! Just msg me on Discord or ask here - there's also a 2.59.0 on sgug-rse-wip that you can use. I'll update that to include the volume manager patch and add another one for 2.62.4 sometime this week.

Also, yesterday I ported some stuff that is known to divide opinions. Personally, I just want to get new stuff running so I really don't care about the semi-religious debate. Thus my Octane now has a messagebus user and a start-up script that starts... dbus :D

Why? Well of course because GTK+3. To get this one going, I had to compile some newer X11 libraries and chose Xorg's latest as my basis. I had some doubts whether things would work nicely against the Xsgi X server on the Octane, but turned out everything works fine. Stuff that's not supported like Xrender falls back as gracefully as it can - the transparency is just not rendered. If someone felt particularly adventurous, it would probably be possible to write a shim that'd implement the Xrender client library API and do the actual drawing with OpenGL.

Some other GTK+3 dependencies were... interesting. libepoxy did not find Python so it decided to try running Python scripts with Bourne shell. Because of that, I thought for a moment that it requires ImageMagick as it tried to run import :D

GTK+3 build consisted mostly of waiting. Also, there's a bug that made it dump core on startup. Apparently IRIX libc bsearch() can give a null pointer to the comparison function under certain circumstances. For now I just #if 0'd out the cache lookup to get it going. Fixing this is trivial, I'll do it today.

If you're worried about gr_osview CPU display, it's all maxed out because the Octane is linking the library while I run the demo.

 

praetor

New member
Apr 26, 2019
8
6
3
So far I've been impressed with SGUG's toolchain build. It's managed to compile everything I've thrown at it. I'll look for the GTK build and build that. Then I can get started on netsurf.
 

onre

SYS 64738
Feb 8, 2019
121
56
28
Toijala, Finland
Fun to see there's interest in these weird projects!

GTK2 and GTK3 are both rather trivial builds once you have GLib. GTK3 has a ton of dependencies but it should be a pretty straightforward build really - more of a test of patience than skill. I built the Xorg stuff in a separate prefix that is not searched by default so I can use PKG_CONFIG_PATH when I'm building something that needs the later client libraries. One odd thing is this; there's no Xregion in SGI's X implementation. It's a small utility library that has been in X source tree since late '80s but for some reason not found in 6.5.30's X at least.

You'll need the small glib patch I mentioned above to make file choosers work. I'll try to get it online today. You can just comment out calls to _resolve_dev_root() in gio/gunixmounts.c to make it work.

Also, Python 3 is build requirement for both GTKs. You can either use the old tardist from ports.sgi.sh or build yourself a shiny new 3.8.1 from sgug-rse-wip. It won't pass all the tests but works enough to build the GTKs and run meson the build tool.
 

onre

SYS 64738
Feb 8, 2019
121
56
28
Toijala, Finland

Here, have a Ninja. Builds on the rse with Python 3. Linking it against DICL is also a possibility - then we could use the latest subprocess-posix.cc.
 
  • Like
Reactions: Elf

onre

SYS 64738
Feb 8, 2019
121
56
28
Toijala, Finland
One more - a multi-problematic patch for meson 0.53.1. Adjust the obvious bit to suit your machine if it's not an Octane.

TODO for this guy includes the following: detect all ip* archs as mipseb, detect which format we're building and set library dir accordingly. Amazing how much dubiosity one can put in less than ten lines of code.
 

Attachments

  • Like
Reactions: Elf

onre

SYS 64738
Feb 8, 2019
121
56
28
Toijala, Finland
Last screenshot was missing the SVG vector icons as @HAL pointed out, fixed thanks to librsvg.

Other than that, i've been busy rebuilding things against the X.org client libs. I've also given a thought or two to writing a Jack backend for IRIX as that's in line with my original idea of what I wanted to run with my newly-acquired Octane - Ardour. i've got almost all of the dependencies in place now and at this rate will be soon seeing how slow it'll be on my Octane.
 

onre

SYS 64738
Feb 8, 2019
121
56
28
Toijala, Finland
So, in the end the GOT may have been a red herring, but stuff was learned which is always nice. Stay tuned.
So - now we've got another piece of software breaking in similar manner. This time it's Ardour. I did some testing tonight and came up with the following thoughts.
  1. binutils multi-GOT mode produces weird GOTs, apparently with extraneous pieces of stuff in them if the GOT acts as both PLT and GOT, as is the case when both data and functions are referred through it. Need to confirm that. Interestingly enough the multi-GOT is just fine is it's only used as a PLT. This has been confirmed with generated code. However, these seem to work just fine even though they look ugly when inspected with IRIX tools. I did a test where I made sure rld had to move the shared library and all the functions returned expected values even after that, meaning that the relocations were correctly calculated for all 20 000 functions and variables.
  2. Does the init code disassembly from the previous page actually show where things go wrong? We calculate a value in $sp just before the indexed jump, amirite? D'oh!
  3. ???
  4. I need more memory for the Octane.
I'll keep you posted once I get farther with this.
 
  • Like
Reactions: Elf

onre

SYS 64738
Feb 8, 2019
121
56
28
Toijala, Finland
COVID-19 has been doing its best to drown me in work.

However, I've slowly been working towards something I've wanted to do for a long time. As a bit of background, some SGI hobbyists make really wild claims about the MIPSpro compiler to the point where it's the ultimate deus ex machina, producing results of absolutely stellar quality in all circumstances. When I began messing around with SGIs in 2018, I compiled a bunch of then-current FOSS with MIPSpro. My practical experience with the compiler was very different from all the hype I had read about it - I had to back down on optimization flags to make software run properly because of optimizer bugs, write lengthy patches because it actually segfaulted on C99 static struct initializers etc.

So, in last couple of weeks I've been running benchmarks and doing tests to get some actual data instead of fantasies. So far it seems like almost all of these claims are simply unfounded. I'll write a lengthy report of my findings, complete with documentation of how I ran the tests so that anyone is free to repeat them and get the same results.
 
  • Like
Reactions: Elf

Elf

Storybook
Feb 4, 2019
253
57
28
I know what you mean on the COVID thing, although it has been the opposite for me :p

I am sure you have noticed but I have not really been around the SGI world for the past two months...

Work-work has continued, but my days are jam packed with various things, ranging from our upcoming birth to preparing for the pandemic and the possibility of economic collapse. We have been trying to push our food inventory out to a year, vacuum packing and dehydrating, Sarah has been learning barbering to be able to cut my hair, I have been trying to source gas mask filters and other supplies, learning to fish, and so on. I need to get around to constructing garden boxes and planting soon too. Living rurally I felt we were always more self-sufficient than average, but there is still a big gap between that and actually being able to survive something like a Great Depression or the collapse in Argentina. With all that going on, the past two months have felt like half a year or more!

Anyways, I am curious to see what you come up with for GCC and MIPSpro! Without having to live with it like you guys have on the active porting team, I kind of understand the MIPSpro attraction. I did always sort of favor the non-GCC compilers: Watcom C and Borland Turbo C under DOS (vs. DJGPP), the Renesas C/C++ compiler (vs. RL78 GCC), the Texas Instruments MSP430 compiler (vs. GCC for MSP430) and so on. Particularly on small microcontroller platforms the trend seems to be GCC produces larger, somewhat slower code, and there is some documentation around that with it primarily being the reason the vendors charge so much for their own compilers, but that's counting cycles and kilobytes. But I was always creating code from scratch. I hear the active IRIX porters have run into a lot of code that is frustrating to compile if not using GCC. :)
 

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu