AIXTOOLS - Open Source Toolbox for AIX

--Michael Felt (talk) 17:02, 8 December 2022 (UTC) Been Offline for several weeks while I solved the problem of paying for the electricity. World issues raised the costs to power the server by over 500% - so it has not been easy.

If downtime occurs again - I am transitioning again. My apologies.

--Michael Felt (talk) 20:04, 18 June 2022 (CEST) Major outage - while I was 2000km away from my server. Three disks, sadly, bit the dust. Lost cooling - and disks die. But I'm back!!

--Michael Felt (talk) 00:17, 21 March 2022 (CET) IP address is changing on 21 March. The site may be inaccessible while the DNS changes migrate through the name servers.

Introduction

AIXTOOLS is a repository of popular OSS packages. The installp format files made available all start as downloads from the respective OSS project download page, or more recently, cloned from a git repository (generally github). The projects have various group owners come from various sources (such as openbsd, gnu, python, sourceforge). When the group has many projects, such as gnu - the package name reflects this (e.g., aixtools.gnu.bash, aixtools.openbsd.openssh). The intent is to have one installable package that will work on AIX 5.3 TL7+, AIX 6, and AIX 7.

--Michael Felt (talk) 08:25, 7 May 2018 (CEST) Some of the Packages are built using AIX 6.1 TL7 (Generally, AIX 5.3 TL7 is used. If a package won't install because it says it needs bos.libc.rte.6.1.7.X, i.e., you need support for AIX 5.3 - contact me via http://forums.rootvg.net/aixtools. Usually, this will not be an issue.)

The guiding principles

• it must be uninstallable: AIXTOOLS does not break AIX. In principle, AIXTOOLS packages can

be installed side-by-side with "RPM-style" software packaging and/or official IBM AIX programs.

• built using XLC and standard AIX run-time environment. Unlike OSS packages built using GCC

additional dependencies are kept to a minimum.

• Some packages cannot be built without using GNU GCC. IMHO, that is a design issue, ie, not truly portable. These packages I tend to ignore.
• Why not more packages? A. Generally, packages come because I need them myself. Once I figure out how to make them work - I share. Other packages come because people have requested help.

2022 and beyond

• AIXTools has never been the the most used AIX OSS site. This has never bothered me, though there times I was jealous of the traffic Michael Perzl got with his packaging of OpenSource4AIX (oss4aix). These days - after nearly 5 years - AIXToolbox (IBM's supported and manned OSS for AIX) has returned from the dead and is, I expect, the most used site for installing pre-built binaries of OSS packages.
• My issues with the way AIXToolbox packages, while a lot less than 10 years ago, are not entirelly abated - so I'll continue being active - even it is only for my own knowledge - and I'll continue to share in as much as I feel it is warrented.
• As AIXTools - I will also provide paid support - whether with setting up AIXToolbox (or other RPM based packaging) - or with setting up an independent (internal) program for OSS utilities on AIX.
• Noteworthy - and I'll have more on the buildaix page is a change I am making to where filesets install. By design that will become /opt/${PROGRAM-"aixtools"} - and for compatibility I'll add symbolic links to binaries to /opt/bin.

Packaging and AIX levels supported

• Most packages are built on AIX 5.3 TL7 - This version of AIX was released with POWER6 around December 2007.
  • AIX 5.3 TL6 and earlier versions is not supported at all.
• Often, packages may be 32-BIT ONLY. Since August 2016 some binaries are released as 64-bit XCOFF. In these cases the libraries are "fat", i.e., they contain both 32-bit and 64-bit members.

--Michael Felt (talk) 08:46, 1 February 2022 (CET) Looking at more improvements to the packaging tool I use buildaix to be able to package `fat` and also have both 32 and 64-bit applications included.

• For "support" post on http://forums.rootvg.net/aixtools. I respond as quickly as I can.

Other sources for tools

If you don´t find what you are looking for you can try either Michael Perzl's collection of RPM's and or the BULL Freeware site. Or, register and post your need on AIXTOOLS Forums.

Starting "today" 21-August-2016 packaging, by default will be XCOFF64 for the executable with dual 32-bit and 64-bit support in libraries. I have run into a few issues - in particular sudo that are not as happy with 64-bit and package it as 32-bit. When package sources have not been (recently) updated, the "FIX" part of the VRMF number will be (incremented) by one. For example, aixtools.gnu.libiconv had VRMF 1.14.0.1 to show the updated status compared to release with VRMF 1.14.0.0 (ultimately - it became VRMF 1.14.0.4 because I had already been 'experimenting'). FYI - this is comparable to the numbers after the '-' symbol with RPM packages (cdrecord-1.9-9 is the 9th packaging of cdrecord version 1.9)

Locating a package

The wiki page Packages is a good page to search, i.e. get a high-level overview of what is available. That page contains a an internal wiki-link to all packages available here. Or, skip the wiki interface and go directly to http://download.aixtools.net/tools

Using AIXTOOLS Packages

The approach AIXTOOLS takes is to package an OSS project into one or more installp filesets. Some projects have a parent project - e.g., GNU is the parent of bash and Apache is the parent of httpd. The naming scheme of AIXTOOLS packages reflects this: "aixtools.$PARENT.$Package.$extension". The extension .rte contains the core functionality: the extension .man.en_US contains (English) man pages and the extension .share contains files that "shareable" by any *NIX.

HOWTO Install AIXTOOLS packages

All packages are in AIX installp format. If you are unfamiliar with the installp command - from the command prompt - the simple instructions are:

1. download all packages you want to install to a single directory (DIR=/some/directory)
2. rm -f $DIR/.toc
3. smit install (and use smit normally)

I will work on instructions on how to install from the command-line - soon. Been getting requests for that.

PATH settings add /opt/bin to your PATH variable

See below for more info - basically - remember to add /opt/bin to your PATH variable. AIXTOOLS tries to not overwrite any potential other packages - unlike many RPM based packages that just overwrite files from installp packages.

Comments, Questions and/or Feedback

Please use the AIXTOOLS Forums Page for comments, questions or any other feedback. Thanks! (Or you could try Twitter @ROOTvgNET)

Using AIXTOOLS on your AIX system

Basics: the buildaix tool, by default, proposes /opt as the prefix - rather than /usr/local which is still the default in most automake/autoconf generated Makefiles. Frequently aixtool packaging follows that convention. Some packages - notably when there are multiple open-source solutions for an API (e.g., openssl, openssl as packaged by IBM and libressl from openbsd) or just a large complex application or tool (e.g., httpd and perl5) I (as aixtools) use a specific project related value for --prefix (e.g, --prefix=/opt/httpd for httpd; --prefix=/opt/libressl for openssl).

Using GNU Directory Variables Guidelines as a starting point buildaix is able to package software in a way that, generally, the aixtools package does not conflict with software coming from IBM (AIX and AIX Toolbox) or other well-known AIX opensource providers. In other words, /usr/local is not touched (it is not even permitted - the buildaix scripts delete anything in $DESTDIR/usr/local). So it will not affect anything you are already doing.

By default three fileset extensions are created: .man, .share and .rte. Files in /opt/share/man and /usr/share/man are placed in the .man section; the files remaining in /opt/share and /usr/share go into the .share extension; and the final fileset .rte (run-time-environment) are all remaining files. The files reamining in /opt and /usr go into the USR portion of the .rte fileset and the remaining files (/etc, /var, /) go into the ROOT portion of the fileset.

• There is one change probably needed - add /opt/bin to PATH - e.g., in /etc/environment to something like:

PATH=/usr/bin:/opt/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java5/jre/bin:/usr/java5/bin Where you place /opt/bin in PATH is up to you of course!

root@x064:[/data/prj/gnu/bash/bash-4.3.33]oslevel -s
5300-07-10-0943

root@x064:[/data/prj/gnu/bash/bash-4.3.33]echo $PATH
/opt/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java14/jre/bin:/usr/java14/bin:/usr/vac/bin:/usr/vacpp/bin

History

AIXTOOLS began simply - porting Apache/ASF httpd and PHP tools needed to host the ROOTVG.net portal. Now I am trying to provide an alternate repository for packages not in the original (anno 2004-2012) AIX ToolBox and/or packages available from other sources such as Perzl's RPM repository. I package using the native installp format because I have had too many complex (read bad) experiences where installp and RPM package management databases collide.

Note: My goal is not to replace the [IBM AIX Toolbox -- RPM Repository]. I package things I use - and things that I am asked to package. I also strive to make my packages about to co-exist with other packages - just add /opt/bin to your PATH variable. I hope that the tools I have packaged here can replace what you have downloaded from other AIX opensource sites.

I started working on porting to AIX in 1997-1998 as a personal education. And up through 2005 I never concerned myself with packaging for others. What I did was for personal use. In 2006-2007 as I went through a process of back-porting from AIX 5.2 to AIX 4.3.3 I became more interested in packaging - I first learned about the tool bull had developed, but more important for me I discovered the AIX utility - mkinstallp.

Again, as a learning experience I used mkinstallp to help me manage the rootvg.net portals software installation. It was not until ±2011-2012 that I got more serious about packaging for others - and started my first sourceforge project - named mkinstallp. This project had it's origin in sone scripts I wrote for ASF (Apache Software Foundation) httpd project (the sub-directory ./build/aix). After two updates to sourceforge mkinstallp I felt the names might be confusing so I took the ASF path and main script name as a new name for the project and "buildaix" was born. And using buildaix I have been packaging GNU and others opensource packages to gradually fill out this repository.

My goal is to replace RPM packaging as much as possible, use IBM xlc as compiler as much as I can (to follow AIX libc rte rules, rather than "suffer" as I occasionally have because of conflicts between GNU libc (more accurately gcc libc differences) and/or even glib (gnome) libc differences. All of them think they are the "better" than the other versions. In short, I try to minimize conflicts by resolving them in advance during packaging. (This is getting much much harder, but I learn a lot - hehe).

Additionally, I want what I package to be able to co-exist side-by-side with standard AIX utilities, as well as RPM utilities (although I do not test the later - I do not load any RPM packages so the only RPM like component is what gets installed together with rpm.rte - such as zlib-1.2.3 while zlib-1.2.8 is current). My approach is to use /opt as my prefix. For most packages the directories were things go are: /opt/bin, /opt/include, /opt/lib, /opt/sbin, etc.. Larger projects get their own prefix: e.g., /opt/httpd and /opt/perl5.

New "policy" - if there is a file that is SO vital in terms of position - with the new version of buildaix - I will be using the pre-verification scripts to ensure that conflicting packages/files are removed before installing my packaging.

• Most packages here are from open source and GNU (R) software portals that publish software distributions. A few are self-made.
• All packages are built for AIX 5.3 TL7 and higher systems (AIX 5.3 TL7 was introduced when POWER6 was announced - June 2007).
• All projects are packaged as installp rather than as RPM. Generally only one package per version is needed. In these cases either there is no oslevel in the downloadable filename - which implies aix537 - or there is an AIX minimum level (e.g. aixtools.*.aix619.I will only load on an AIX system at AIX 6.1 TL9 and higher). The reason for additional versions is an incompatibility in a runt-time library (e.g., openssl) where the name of the archive changes internally (again openssl went from openssl-0.9.8 to openssl-1.0.0).

• None of these packages are intended for AIX 5.3 TL6 or earlier. If you need something for those levels you should checkout http://www.bullfreeware.com and/or http://www.perzl.org/aix/.

• The other repositories generally package in an RPM format.

FAQ

Why not use RPM format like AIX Toolbox and Perzl packaging?

The key difference between the IBM AIX Toolbox approach and AIXTOOLS is the packaging. AIXTOOLS uses the native installer (installp) while the Toolbox approach uses RPM. A second distinguishing element is the preferred compiler.

As much as possible an IBM C/C++ compiler is used to port/build the projects (e.g,. bash or httpd). This approach minimizes the need for a parallel run-time environment that applications compiled by GNU compilers (e.g., gcc) need. This means most AIXTOOLS installs and operates with a minimum of additional dependencies - GNU gettext being the most common dependency. (Gettext provides the language support for GNU based applications and compares with what AIX calls NLS (National Language Support)). The final distinction is the oldest level of AIX supported. AIXTOOLS do not support - read are not expected to work at all - on AIX 5.3 TL6 and earlier (roughly levels that were current prior to May 2006) while many Toolbox RPM's will still install on AIX 5.1 (some even on AIX 4.3.3).

Why would I want to add /opt/bin to my PATH ?

AIXTOOLS places it programs in /opt/bin and /opt/sbin OR /opt/package-name/*bin (e.g., /opt/httpd/bin and /opt/httpd/sbin). This is why adding /opt/bin to PATH may be important, read is recommended. aka ease of use.

The goal of AIXTOOLS packaging is to not touch what is already there. That is, RPM packaging and AIXTOOLS (when AIXTOOLS is installed last!) can co-exist side-by-side. One of my reasons for starting AIXTOOLS is due to the RPM packaging "overwriting" already existing files, sometime in /usr/bin - and making uninstall impossible because they did not save what they replace.

So, programs that exist in /usr/*, e.g. symbolic links from /usr/bin to /opt/freeware/bin - remain until you remove them, or replace them.

What about RPM packaging and the common use of /opt/freeware/* ?

The popular RPM packaging sites (IBM AIX Toolbox, BULL Freeware, Michael Perzl) use the location /opt/freeware - chosen by BULL many years ago.

The goal of AIXTOOLS packaging is to not touch what is already there. That is, RPM packaging and AIXTOOLS (when AIXTOOLS is installed last!) can co-exist side-by-side. One of my reasons for starting AIXTOOLS is due to the RPM packaging "overwriting" already existing files - and making uninstall impossible because they did not save what they replace.

The only exception AIXTOOLS makes is to replace symbolic links in /usr/lib that point at libraries in /opt/freeware/lib - as needed. To maintain compatibility - the contents of the old libraries are copied into the new AIXTOOLS library - AND - the old library is left asis. When/if AIXTOOLS is removed the symbolic link to the old, still existing library - is restored.

The objective is that existing programs that depend on the old, read ancient, libraries will continue to run.

Where are the packages for AIX 6.1, 7.1 and 7.2?

Most of the packages are built on a system running AIX 5.3 TL7 release (5300-07-SP-WWYY) Thanks to binary compatibility these also run on higher/later releases.

Initially, the level of AIX the package was built on could be identified by the file ending - generally .537.I. This extension .NNNN.I specifies the lowest level of bos.rte.libc that is needed to be able to install the package. If the ending is .5312.I then AIX 5.3 TL12 is needed; with .618.I AIX 6.1 TL8 is needed; etc..

Due to continuing confusion (because of the RPM naming conventions it seems) I have
stopped with adding the build system oslevel to the filename.

Remember: None of the packages here will install, or run on AIX 5.3 TL6 or older/lower.

Where are the 64-bit packages?

• Note: starting in August 2016, by default, packages are built as 64-bit XCOFF executables but will also contain 32-bit libraries.

Initially, AIXTOOLS only packaged in 32-bit size. Currently - some of the packages are being updated to include 64-bit members in the libraries - as well as 64-bit versions of the applications. The first packages will be to include both 32-bit and 64-bit libraries and applications are libiconv and gettext.

If you are in dire need of 64-bit, and/or 32 and 64-bit libraries leave a post on http://forums.rootvg.net/aixtools!

CVE chasing, OpenSSL and AIXTOOLS packaging

For OpenSSL - the packages needing OpenSSL are being updated (relinked) so that they use OpenSSL-1.0.0.so or higher (internal name for OpenSSL-1.0.1). This compares with openssl.base.rte-1.0.1.500 and later. This level is also available for AIX 5.3 via AIX Web Download Pack Programs. You will be prompted for a IBMid before you may access the IBM provided Webpack downloads such as updated OpenSSL.

What's in a name?

AIXTOOLS packages will have names like this:

aixtools.gnu.bash.4.3.33.0.I
aixtools.gnu.bash.4.3.33.0.aix537.I
aixtools.gnu.bash.4.3.33.0.aix617.I

The first part of the name is obviously aixtools, the second and third parts of the name is the parent project of the project followed by the project name (in this example the project is bash and the parent project is GNU). The next part is the four numbers that follow. Their interpretation varies per project - for bash they mean version 4.3 patch-level 33, because that is how the bash projects administers itself. For installp - these are the VRMF (version release modification fix) numbers that installp uses to differentiate software levels. The last part identifies the lowest level of AIX that this project will install on, e.g. aix537 means it will install on AIX 5.3 TL7 and later (The IBM runt-time environment is supported from older to newer, but not from newer to older. Think of it as knowledge that the bos.libc.rte has for applications rtl (run-time linked) with earlier versions of bos.libc.rte. And, lastly - as a convention AIXTOOLS uses .I to hint that this is an INSTALL, not an UPDATE package.

When the aixXXX is missing - installing on aix537 or later is implied. When there are two versions (e.g., endings in aix537 and aix617 - this means the aix537 will install in anything later than aix537 (but probably will not work in aix617 or later) and the aix617 ending will install (and work !) starting with AIX 6.1 TL7 releases.

Check out the buildaix page for more info.

Does AIXTOOLS bundle packages

I have defined a Bundle is a collection of packages that are needed to install something useful. In AIX terms this is a .bnd file with packages that may or may not resolve dependencies. For AIXTOOLS I am starting to "bundle" individual filesets into a BZ2ZIP compressed tar file that contains all the installp available from AIXTOOLS in a single download. An AIXTOOLS bundle will not contain files that come from IBM - notably, openssl.base. So, some of the wiki pages, e.g., wget also have a bundle link.

Cannot find what you are looking for?!

• I am not trying to be an improved version of the AIX Toolkit. In particular, when the dependencies on a GNU package gets so deep (e.g., will only compile against gcc) I am not likely to pursue it to the end.
• Other times, because of specific requests I work on AIX specific patches (e.g., for python) so that it (e.g., python) can install without 10 to 20 additional RPM dependencies (that cannot be uninstalled collectively).
• If there is time, post a message on my forums (http://forums.rootvg.net/aixtools) that you are looking for something that is not here. I will be in touch, i.e., reply on the forums asap.
• However, if you are in a rush, and looking for improved versions of what is available on IBM AIX Toolbox for Linux Applications I highly recommend Michael Perz's AIX Open Source Packages and BULL Freeware - for more thorough (in RPM format) choices. Also - Perlz and BULL continue some support, rather packages, for AIX 5.1 (maybe earlier) while I am working from AIX 5.3 TL7 as my baseline.

Packages (ready to go) and Projects (in progress)

For now I see two main areas: Packages and "Work in Progress" aka Projects.

Packages aka installable filesets

Things that are packaged - and "ready for use". Quick Access is available via the Packages menu aka Sidebar on the left.

Projects -- aka 'Challenging Packages'

A project is something anything that needs more than just running the command buildaix to package the FOSS source download.

Most of the time the additional work is minor, or is should have been simple and working the FOSS package maintainers - additional work is removed. Other times I will be motivated to try and fix it witin buildaix.

Other stuff in Package pages:

• Lessons learned: basically chatter about what I learned as I completed a package
• Things - holding me back from completing a package.
• A personal project - for examplebuildaix for starters.

When does a Project become a Package?

• A package begins as a project or a downloadable tarball - wget something.tar.{gz|bz2|xz} followed by decompress into a source tree.
• Some projects do not become a package right away, or at all. Basically - either configure fails, or make fails - and often both.
• Once make install to DESTDIR succeeds a package is ready to be packaged as an installp package and is made available somewhere on AIXTOOLS DOWNLOAD PAGE
• A finished project is a "completed" package available as a download.