89AED8579B22F0F7CA4986CAE5FD1A11 aixtools.zlib.184.108.40.206.I F150F1EC7D69C46317FEB810D83EEB3A aixtools.zlib.220.127.116.11.I 30F0FEE8634EE54F1CA28C8DAC1DED7D aixtools.zlib.18.104.22.168.I
Version: 1.2.11 Released: 15 January 2017 Source: http://www.zlib.net/ Depends on: (nothing!)
--Michael Felt (talk) 19:13, 2 February 2017 (UTC) repackaged as aixtools.22.214.171.124 so that it includes the old SYSV versioned names of the .so members. I noticed my https would not load when I updated zlib because it wants zlib-1.2.8 specifically. So, I am confident that any packages that rely on aixtools.zlib.rte will work as expected
If you have aixtools.zlib.126.96.36.199.I installed I recommend you update with aixtools.zlib.188.8.131.52 asap.
Version 1.2.11 has these key improvements over 1.2.10: Fix deflate stored bug when pulling last block from window Permit immediate deflateParams changes before any deflate input
Due to the bug fixes, any installations of 1.2.9 or 1.2.10 should be immediately replaced with 1.2.11.
Version 1.2.10 has these key improvements over 1.2.9: Fix bug in deflate_stored() for zero-length input Fix bug in gzwrite.c that produced corrupt gzip files
Due to the bug fixes, any installations of 1.2.9 should be immediately replaced with 1.2.10.
Version 1.2.9 has these key improvements over 1.2.8: Improve compress() and uncompress() to support large lengths Allow building zlib outside of the source directory Fix bug when level 0 used with Z_HUFFMAN or Z_RLE Fix bugs in creating a very large gzip header Add uncompress2() function, which returns the input size used Dramatically speed up deflation for level 0 (storing) Add gzfread() and gzfwrite(), duplicating the interfaces of fread() and fwrite() Add crc32_z() and adler32_z() functions with size_t lengths Many portability improvements
The new library is in /opt/lib/libz.a The old library, should you need it - is still at /opt/freeware/lib/libz.a The symbolic link in /usr/lib not points to /opt/lib/libz.a.
Legacy AIXTOOLS notes for ZLIB aka LIBZ
The latest version is libz-1.2.8. This is packaged as aixtools.zlib.184.108.40.206.I
As far as zlib aka /usr/lib/libz.a is concerned - the latest AIX version seems to be equivalent to libz-1.2.3. The file/pathname /usr/lib/libz.a is a symbolic link to /usr/opt/freeware/lib/libz.a while the actual archive is located at /opt/freeware/lib/libz.a (note: /usr/opt/freeware is a symbolic link to /opt/freeware - your guess is as good as mine!)
The default AIX packaging has only two members in the archive (try ‘ar tv /usr/lib/libz.a‘) - libz.so-1 and shr.o. The default make by libz makes both a libz.a with multiple members with names ending in .o (the style for static libraries on many systems) and a second 'library' libz.so.1.2.8. This second 'library' is compiled so that it can be linked in dynamically.
When you go back far enough in time some versions of UNIX - noteably Solaris - had two versions of the same library - a .a version with static-linked members (object file ending is .o) and a library with 'shared objects', hence the .so ending.
From memory, starting with AIX 4.1 (in 1995) all AIX .o files were PIC (position independent code) and therefore shareable. AIX also has a BSD compatible history - so the library names stayed with .a and the AIX loader looks for (dynamic) libraries with '.a' endings while other UNIX, as well as Linux, (also) look for libraries with .so endings.
The interesting trick that AIX can now apply is that it can have two different .so library members in a single .a archive. Just look at /usr/lib/libssl.a on AIX 6.1 or later - you will find both libssl.so.0.9.8 as well as libssl.so.1.0.0.
Issues I have had with packaging and standard AIX tools
The most noteable problem I had is with AIX openssh - in particular, the sshd daemon. If I would install my aixtools.libz.rte and have /usr/lib/libz.a point at it - the AIX openssh.base sshd daemon would not load. Not good.
This has taken a while to figure out (my previous packaging for zlib dates from June 2013 and puts everything in /usr, and does not have the .so member included in it - this will cause problems - I am nearly certain. 'HOWEVER', the new packaging, with an increased version number so it will replace the previous one installs to /opt/lib and /opt/include - and it our job (a yet later packaging will include scripting to do this for you) to create symbolic links from /opt/include to /usr/include and /opt/lib to /usr/lib.