Step 1

create a script to capture the aa_elflibs from the build machine andput them
into a dir.
update the aaa_elflibs slackbuild to copy them into the unpacked elflibs archive.

===

This build system's complexity is astounding for what it actually needs.

This way can be automated, when run on the single lead builder.

SAVE existing libraries:
when aaa_elflibs is in the ChangeLog SUD batch, a .sud-helper (may need coding)
runs on the build machine, takes an inventory of the Slackware64 aaa_elflibs package
and (accomodating lib/lib64) copies all of the same library file names from the 
file system into a staging directory within aaa_elflibs' source dir.

It can use an exported SUD tmp location to unpack the existing archive and update it.


When running through r2b, aaa_elflibs :
  cd unpack
  tar xf  elf libs archive
 * rsync -Pavv $PORTCWD/staging/* . 

NOTE: think about how to maintain symlinks.  Check through the find_aaaelflibs
      script for inspiration.  May be as simple as explodepkg'ing the x86 package
      and using a filesystem trawl to copy the same versions from the build machine's
      file system.  This is the target.

 * takes inventory of the Slackware64 txz package to determine the
   content

 * copy the list from the dir in which the elf archive + staging is.

The idea is that prior to the update, the build machine will have the libraries
that have been added to the package to support a transition.
At the end of the build, the build machine will have the latest versions of
each library, and it'll merge the older libraries from before the build.

We'll also maintain the elflibs archive which acretes libraries. The purpose of
this is to handle any situations that requires an old core library.
It has happened once or twice but it's worth keeping around since it's automated!