pksgsrc for IRIX 6.5.30

Unxmaal

Administrator
Feb 8, 2019
44
16
8
I've been working off and on for several months to get pkgsrc working with IRIX 6.5.30.

My reasoning for using pkgsrc is that it provides dependency resolution, and since it used to work with IRIX, it might could work with IRIX again in short order.

My current notes are always posted here: https://github.com/sgidevnet/sgidevnet.github.io/blob/master/wiki/unxmaal_pkgsrc_build_notes.md



Progress has stalled due to a nefarious bug that manifests during bmake install . Several packages compile without needing modification, but the bmake install process improperly copies pkgsrc's temporary wrapper scripts into the "destdir" directory for packaging instead of the compiled binaries.

As you can see from my notes, I did quite a bit of debugging for libtool, but ultimately was unable to determine why it was failing.

I can manually work around this defect by manually copying the compiled binaries and libraries from .lib into the .buildlink/ directory. However, this is not sustainable, and doesn't work at all with more complicated packages like Perl.

Any assistance (or even corroboration) would be much appreciated.
 

onre

Administrator
Feb 8, 2019
59
18
8
You meant libtool's wrapper scripts.

This is a particularly irritating problem. In my opinion there are two practical options for this.

  1. dive deep enough into libtool to figure out what's happening differently on IRIX vs. NetBSD or whatever.
  2. write an interface-compatible script which does the right things and only works on IRIX.

Of which neither seems particularly appealing but 2) might be less painful.
 

hammy

Member
Jun 1, 2019
65
32
18
UK
I'm afraid I'm no expert in pkgsrc (and I hope you'll forgive me if I don't want to become one .-) ) .

Another option open to you - regenerate the autoconf/automake/libtool infra in those projects using a known good version of these tools.

I've personally seen projects that needed an "autoreconf" before they would properly compile/do things on IRIX.

The tricky part of this route of course is that you need all the latest versions of the supporting tools of autoconf/automake/libtool to properly be sure the new versions you use are working correctly (so sed, make, awk, perl, bash etc).

It's one of the reasons I went down the route of "didbs" - because I couldn't trust the existing nekoware or random hand-compiled packages that people would post.

FWIW - if you have a recent autotools - you could maybe try an "autoreconf" in the root of the sources and see if that helps at all.
 

Unxmaal

Administrator
Feb 8, 2019
44
16
8
I'm afraid I'm no expert in pkgsrc (and I hope you'll forgive me if I don't want to become one .-) ) .

Another option open to you - regenerate the autoconf/automake/libtool infra in those projects using a known good version of these tools.

I've personally seen projects that needed an "autoreconf" before they would properly compile/do things on IRIX.

The tricky part of this route of course is that you need all the latest versions of the supporting tools of autoconf/automake/libtool to properly be sure the new versions you use are working correctly (so sed, make, awk, perl, bash etc).

It's one of the reasons I went down the route of "didbs" - because I couldn't trust the existing nekoware or random hand-compiled packages that people would post.

FWIW - if you have a recent autotools - you could maybe try an "autoreconf" in the root of the sources and see if that helps at all.
The issue is with pkgsrc itself. This happens if packages use autoconf or not. I even tried replacing pkgsrc's libtool with one I made myself (and autoconf'd!) and it still put things in the wrong place.
 

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