[Raion]

> Did you do updates via git/cvs or some other SCM tool

I just used a tarball with a static setup. If we fork ports and do this for real, we will need to pare it back aggressively to both save on space/inodes and make maintenance easier. I have worked as a p;rt maintainer for both and FreeBSD ports can use the perl based tool Magus, from MidnightBSD for building software (and because it's perl, it shouldn't be too bad to get tardists going)

> NOTE: I am no secret squirrel, I am happy to fail in full public view, just as I make a bit of a fool of myself when I try to use the kids skateboards ;-)

Without getting into a diatribe: I would do this, but I'm under a microscope of scrutiny. There is a group of users who I won't say, who aren't here but stalk what I say extensively and spread nasty rumors behind my back. They also try to actively sabotage my development efforts by talking shit to the people who want to collab with me. So I try to get things into semi usable states before I have them out there.

But anyways, I'll salvage it at some point from my system, get it up online and write some documentation on how it works. It'll take a while but feel free to poke me about it. If you're serious, I can handle the port maintenance and some of the porting side of things and well as help with restructuring using various custom hooks, I just need people more experienced with bmake for it.

That's all. I'm out of town right now but I'll be a bit more able to handle it.

[jwhat]

Hi Raion,

I already have a FeeBSD Ports fork, as I semi regularly raise Bug reports to the FreeBSD team on one thing or another ;-)

Here is my fork: https://github.com/zebity/freebsd-ports/tree/main

I have already cloned this down onto my Fuel and will start on IRIX-6.5 branch.

Or rather it is in the process of cloning, as doing stuff on old IRIX box is slow ;-)

As part of boot strap I just used SGUG-RSE git, but I will replace this with source build and hopefully make it so can bootstrap via SGI Freeware ....

EDIT: Elected to export IRIX disk with Port Git repo via NFS, as RSE git does not work with password token, that is mandatory with GitHub.

But I am gettting way way ahead of myself already.

NOTE: the reason I am not using SGUG-RSE beyond bootstrap is because it is a "binary" distribution mechanism and I just want to have a source based approach.

EDIT: see above RSE Git does not support http token auth.

On trimming FreeBSD Ports tree, I don't see the point, you can just ignore the stuff that you don't use, trimming is just extra work.

Anyhow approaching the brick wall fast and likely to have a crash soon.

As always thanks for going to trouble of keeping IRIX Network up and running.

Cheers from Oz,


jwhat/John (& zebity on github)

[Raion]

> On trimming FreeBSD Ports tree, I don't see the point, you can just ignore the stuff that you don't use, trimming is just extra work.

Because it's extra dependencies to carry around and inodes. Space is at a premium, and a few GB can make a huge difference, as can a few tens of thousands of inodes. Inodes are especially an issue for IRIX due to older XFS.

[markh]

Hello jwat,

my apologies for not replying sooner. Summer (too hot in my computer room) and then work got in the way of trying to do anything with my Sgi machines.
I did the nekoports scripts, because I wanted to get something running without getting too many dependencies that I needed to get running first. This is also why the perl script works with the perl shipped with IRIX as that was one less dependency.

I agree with you on the maintaining of the dependency lists. That is something I have been delaying as much as possible as that will complicate everything.
I am following you FreeBSD Ports port with interest and I hope you succeed in getting it running.

The reason I do the inst packages is that this is simple for regular users to install. I think not everyone has the MipsPro compilers installed or wants to compile everything all the time. Compiling git on my Indigo2 takes quite a while and for open source software that is not a big piece of software.

[jwhat]

Hi markh,

thanks for getting back.

I understand where you are coming from.

I agree that the outputs from build process should be inst usable tardist files.

I have never used IRIX packaging tools so if/when I get to that point, it would be great to get assistance.

Raion has also done work with building inst package.

My model (in my mind is like this):
- (git clone port tree via NFS) | (irix ports bootstrap process) | (via ports boostrap dialog4ports) | (ports build openssl | pipe install into inst) | * (ports build others | pipe install into inst)

So core repeatable build / install process should create inst tardist package which can be installed via inst.

On local machine install -> inst/swmgr (rather than BSD install), but result is also set of tardist that can be feed up to binary repository for other to use via inst/swgr install.

Now I have played with this a bit more, I can see where Raion is going with Port "flavours".

This would allow FreeBSD Ports to become "xNIX-Ports" and a bit more liberated from FreeBSD and other BSDs.

Cheers from Oz,

jwhat/John

[markh]

I have done a bit of work again.
I have added tardists to the releases of the github repository (see https://github.com/markhellegers/nekoports/releases). I am not sure if that is allowed, so we will see if Github doesn't like that. But as long as they are there you can download the tardists.

I have also mirrored the repository on the IrixCE Gitea server. This is more a bit of an experiment, but might be handy for those that don't want to use Github.
I might switch over to that one as Github is getting a bit more annoying with security stuff (access tokens and two factor authentication).

[Richard42]

Darn, I wish I had read this thread all the way through to find markh's tardists of git 2.36.  I also set off on a similar quest to build Git for 64-bit IRIX 6.5.30 about a week ago and spent an inordinate amount of time on the task.  I did finally get Git 2.38 built and running on my machine, but I went through a lot of trouble and just wanted to go over some of the issues that I encountered for the next poor soul who tries the same thing.

I got my first SGI machine ever a few months ago and just got it running at the beginning of the year. I install IRIX 6.5.30 from scratch using LOVE and wanted to keep the software install as simple as possible. I have a 9GB drive in this machine and it's nearly full after I finished installing everything I wanted. I started with everything from IRIX 6.5.30 and the MIPSPro C++ 7.4.4 and SGI freeware CDs.  I also installed a bunch of stuff from nekoware and xenoware.  I think the RSE project is a great idea but for this particular machine I wanted to keep everything simpler: stick with the OG SGI compiler and have software that's install through the IRIX package manager and built locally in /usr/local.  I don't care about running newer GCC for newer C++ standards; C99 and C++03 is perfect for what I want to do. I am most concerned with having a compiler which generates the most performant machine code.  Does anyone know if GCC 8/9/newer makes faster code than MIPSPro 7.4.4?

So, in no particular order, here are a bunch of things that I learned, problems that I encountered, and questions that remain:

• zlib was easy to build and install; I think I did it like this:
  

1. setenv CC c99; setenv CFLAGS '-64 -mips4'; setenv LDFLAGS '-64 -mips4'; ./configure --prefix=/usr/local
   

• I ran into some problems because I was trying to make 64-bit builds and the nekoware software is all 32-bits.  Is it worthwhile making 64-bit builds for the MIPS r10k or is better to make everything for MISP3/32-bit? In the PC/x86 world I jumped over to 64-bits as soon as AMD released the Athlon 64 / Opteron and never looked back.
  
• When I was building Git, something in the build system kept pulling in the 32-bit /usr/nekoware/lib32 and /usr/nekoware/include folders even though I hadn't specified them on the command line. I assumed it was because I was using the nekoware "bash" shell, so I switched to use the xenoware bash instead.
  
• TCSH is not so great. Everything expects BASH, and there is a lot of shell script code in the Git build process, so this caused some problems.
  
• I have a love/hate relationship with autotools. It's great when it works but it really sucks when it doesn't and it's super convoluted and hard to diagnose and fix and causes super shitty problems like random bits of shell script code ending up in the Makefile.
  
• I did build and install autoconf 2.72, automake 1.12, and m4 1.4.19 and they seemed to mostly build and install just fine. But when I tried to use it to create the configure files in various projects, I always got it to run and complete, but the resulting configure and/or make would fail in some stupid way.
  
• That's when I discovered, when getting source packages of open source projects on github, you always need to get the Release files and not the Tag files, because they pre-build the configure file in the Release archive, whereas you have to build it yourself with autotools in the Tag archive. I should have known this already but for some reason I didn't.
  
• You have to download a certificate PEM bundle and build it into your SSL/TLS library if you want authentication to work (which you do).
  
• There is something jacked up with the terminal GUI app in IRIX, I think it's called WinTerm? When copy/pasting stuff from another window by selecting it with the mouse, hovering over the terminal window, and pressing the middle mouse button, it trips over itself when handling control codes. When trying to paste stuff into a command-line editor like "joe" or "vi", it will ignore linefeeds, dump out partial control codes like "[m26", write over itself, put the cursor in random places, etc. Similarly, when using "dbclient" to ssh into a remote linux machine and doing the same thing there (copy/pasting via middle click), it has the same problems. Does anybody know how to fix this? Also, is there a key combination to paste from the clipboard into the WinTerminal window?
  
• Something is broken with OpenSSL. It seems like the build (though long) went fairly smoothly.  I built both OpenSSL 1.1.1q and 3.3.2, and they had the same problem. I think I built them like this:
  

1. /opt/xeno/bin/perl ./Configure irix64-mips4-cc --prefix=/usr/local/ssl --openssldir=/usr/local/ssl
   

• So it seems that OpenSSL should build on irix64 / mips4, because they have an explicit setting for it. I ran into a problem with the OpenSSL 3.3.2 build whereby the command line to create both libcrypto.so.* and libcrypto.a were too big for the shell/kernel to handle, so I had to split up the linking into multiple steps for the static library, and use and external file containing an input list with -objectlist for the shared library.
  
• But in both cases (1.1.1q and 3.3.2) the resulting OpenSSL install seemed to be good and worked to decode certs. But when I built cURL against these OpenSSL builds and ran curl against an https site, it always failed early during the SSL handshake while trying to decrypt the first packet with an AES_256_GCM cipher. I assume it's an endianness or 64-bit problem? Seems unlikely because OpenSSL supports so many platforms, but both versions failed exactly in the same way. And I traced it down using the debugger several layers until I got to the macro'd-out mess of cipher code in libcrypto and said F it.
  
• So, GDB kinda works. That's awesome.  But I ran into problems with "strace", which I think is in nekoware.  It starts out and works great, but after dumping a few pages of trace log, it just stops. Anybody know why this happens and how to make it continue?
  
• So I got mbedTLS 2.28.0 to build and work properly with cURL. I also built v3.6.2 a few times and it probably would work just as well but I ended up using the older version just because I perfected it first. I had to make some build/code fixes and got it to build like this:
  

1. fix 3rdparty/Makefile to hardcode folder path
   
2. fix makefiles for "else ifdef" on same line
   
3. add lines to library/net_sockets.c ("#define _NO_XOPEN4 1", "#define _NO_XOPEN5 1") just before: #include <sys/types.h>
   
4. gmake no_test SHARED=1 CC=c99 'CFLAGS=-64 -mips4' 'LDFLAGS=-64 -mips4' prefix=/usr/local WARNING_CFLAGS='' APPLE_BUILD=0 -j3
   
5. mkdir /usr/local/mbedtls
   
6. gmake install DESTDIR=/usr/local/mbedtls
   

• I got cURL 7.8.80 to build with this configuration:
  

1. ./configure CC=c99 'CFLAGS=-64 -mips4' 'LDFLAGS=-64 -mips4' LIBS='-lpthread' --with-mbedtls=/usr/local/mbedtls --with-ca-bundle=/usr/people/pyro/software/cacert-2024-12-31.pem MAKE=gmake
   

• I ran into a weirdness with the pthread library too. It seems that under some circumstances, you can build a project (this happened with openssl I think) which uses pthreads, and it will build and link fine, and run fine, but when any of the pthread functions are called, they fail. What's up with that? It's like a stub library is auto-magically getting linked in which just returns -1 for everything. The solution to this is to add "-lpthread" to the linker command line.
  
• I was able to successfully build and install Git 2.38 with the following changes:
  

1. Rename atfork_parent() in run-command.c to not conflict with system function
   
2. in http.c, cast (void*) result to (FILE*) in argument to fileno() in http_request_reauth()
   
3. change first line of generate-cmd.sh to: #!/usr/nekoware/bin/bash
   
4. manually run the generate command: ./generate-cmdlist.sh command-list.txt > command-list.h
   
5. comment out a bunch of lines in Makefile to avoid building the tests
   
6. gmake NO_TCLTK=1 NO_EXPAT=1 NO_GETTEXT=1 NO_SSH=1 NO_OPENSSL=1 NO_PERL=1 NO_PYTHON=1 INLINE='' CC=c99 'CFLAGS=-64 -mips4 -I/usr/local/include -I/usr/local/include/curl' 'LDFLAGS=-64 -mips4' CURL_LDFLAGS=-lcurl LIBS='-L/usr/local/lib -L. -lgit -lgen xdiff/lib.a -lz -lpthread -L/usr/local/mbedtls/lib -v' SHELL_PATH=/opt/xeno/bin/bash prefix=/usr/local V=1 -j3 git
   

• It still requires linking against OpenSSL even though I told it NO_OPENSSL=1
  

So I think that covers most of my ridiculous build quest. Let me know any suggestions or tips and tricks. I absolutely love the SGI machine and IRIX and am very happy to have this all up and running and to be working on my game now.  The real end goal of this is to port over a game that I wrote over 20 years ago when I was learning OpenGL, and make it work with 3D glasses and demo the system to the public. I am a part of a few different groups of vintage computer/game collectors in southern california, and am hoping to have this ready to show in time for CLASS (Commodore Los Angeles Super Show) in Burbank in early April.

[Raion]

Hello Richard,

Sorry for skipping over this post, I have been preoccupied:

> I ran into some problems because I was trying to make 64-bit builds and the nekoware software is all 32-bits. Is it worthwhile making 64-bit builds for the MIPS r10k or is better to make everything for MISP3/32-bit? In the PC/x86 world I jumped over to 64-bits as soon as AMD released the Athlon 64 / Opteron and never looked back.

Most offer n32 binaries for widest compatibility. the O2 and oldier SGI machines like the Indigo2, Indy etc run 32-bit kernels and n64 ABI stuff doesn't work.

> When I was building Git, something in the build system kept pulling in the 32-bit /usr/nekoware/lib32 and /usr/nekoware/include folders even though I hadn't specified them on the command line. I assumed it was because I was using the nekoware "bash" shell, so I switched to use the xenoware bash instead.

It can also be LDFLAGS or other things.

> I did build and install autoconf 2.72, automake 1.12, and m4 1.4.19 and they seemed to mostly build and install just fine. But when I tried to use it to create the configure files in various projects, I always got it to run and complete, but the resulting configure and/or make would fail in some stupid way.

I got a netbsd box I run autogen and stuff on and move the project over. Much less painful.

> There is something jacked up with the terminal GUI app in IRIX, I think it's called WinTerm? When copy/pasting stuff from another window by selecting it with the mouse, hovering over the terminal window, and pressing the middle mouse button, it trips over itself when handling control codes. When trying to paste stuff into a command-line editor like "joe" or "vi", it will ignore linefeeds, dump out partial control codes like "[m26", write over itself, put the cursor in random places, etc. Similarly, when using "dbclient" to ssh into a remote linux machine and doing the same thing there (copy/pasting via middle click), it has the same problems. Does anybody know how to fix this? Also, is there a key combination to paste from the clipboard into the WinTerminal window?

IIRC you can use right click menu to copy stuff. I'm mostly headless nowadays.

> Something is broken with OpenSSL. It seems like the build (though long) went fairly smoothly. I built both OpenSSL 1.1.1q and 3.3.2, and they had the same problem. I think I built them like this:

I built libressl. Use it

> So, GDB kinda works. That's awesome. But I ran into problems with "strace", which I think is in nekoware. It starts out and works great, but after dumping a few pages of trace log, it just stops. Anybody know why this happens and how to make it continue?

If you're building with mipspro, use dbx(1). If it's not installed, get the prodev workshop stuff from ftp.irix.host. GDB on IRIX can work but it's funky.

> I ran into a weirdness with the pthread library too. It seems that under some circumstances, you can build a project (this happened with openssl I think) which uses pthreads, and it will build and link fine, and run fine, but when any of the pthread functions are called, they fail. What's up with that? It's like a stub library is auto-magically getting linked in which just returns -1 for everything. The solution to this is to add "-lpthread" to the linker command line.

Yep, add -lpthread because IRIX threads are weird af.

At the moment i'm rebuilding the foundation of nekoware, so keep in mind nekoware stuff is old and crusty. I'll consult with you sooner or later on this in more detail