Shared Object Tree Decisions

The glibc issue has been worked out.

I needed to introduce a way to:

  • Ensure a consistent, reproducible environment between builds.
  • Allow multiple-session builds.
  • Audit build options and configuration at build script run time.
  • Streamline logging for RCA on failures.

And that I did:

As you can see the last build is always dated in ISO 8601 format, after which you’ll see the package.  Subpackages are nested though im reconsidering that.

Included in each log set are the make results in build.log, the build_script is the script actually automating that build when the logs were generated, the configure.output.log is the output of the ./configure command where applicable, environment.log is showing the sorted output of env so that the runtime variables can be inspected, make install goes to install.log, and misc.log includes any other actions not already accounted for, mostly health checks on the resultant build targets.

This new addition quickly got surro past the glibc hurdle and on past libstdc++, binutils pass 2, and into gcc pass 2.

This the last failed configure log.  This is happening because I changed the shared libary management scheme mentioned below between the last and current package so the the whole build will need to run:

Luckily because I’m “automating it before doing it” for everything it only takes about an hour to start from square zero now, so we are never really starting from square zero anymore.

I am expecting relatively smooth sailing once we make it out of relinking GCC after this second pass.  I want to get done and out with the compiler tools so I can focus more on package selection.

Determinations were made by the Council Of Greybeards:

For shared libaries and managing architecture coherence we’re going with /lib{,32,64} and merging /usr/* dirs.  This should be simple, straightforward to manage, and hard to break.  /lib will only exist with populated symlinks for a 32bit glibc shared object that is actually a symlink to whats in /lib32.  I am sure this will have slight additions when LSB is introduced, but remember we are building Foster currently which is the system that will build the LSB-compliant Surro-Linux so we actually don’t care about LSB implementation for this round — even if we are going care when we actually boot that environment.

Oddly enough, while I was intending to mimic Red Hat’s directory structure for shared library management and avoid old Debian/Gentoo/Arch Linux FS trees , this is actually the functional equivalent of being right in between both models as Red Hat uses /lib{,64} and older Debian and Arch uses /lib{,32} each for opposing architectures, and neither of which feels sane to me except as legacy footprints– although I am perfectly willing to admit their maintainers know much more about this topic than I do.

Regarding multilib, I’ve got some reading to do on this topic to be more informed.  Here’s what’s on my plate:


Luckily for us, this change will be both FHS and LSB compatible so we will be able to carry the same design into SURRO if it works out well.

I just wanted to post updates now that we’ve had some as I’ve been caught up with managing life things and haven’t had much time to work on this.  Once foster is bootable and the automations are complete I’ll be opening up the VCS to make this a collaborative effort.