Multi-arch binaries (was Re: [ut2004] ./ut2004-bin: error while loading shared libraries: libstdc++.so.5)

[Douglas Wade Needham]

Methinks?  SCA?

I will start off by agreeing that a single disk is cheap when compared
to many programmer hourly rates.  Even at my most favorable rate, an
hour of time could easily buy me a nice drive, and depending on what
it is and who I am doing it for, a top-end drive is not out of the
question.  But I have been programming professionally for over 20
years and had to deal with this sort of thing, including
"fat-binaries" before (like supporting multiple Sun 3/4 architectures,
or multiple Sparc architectures, etc.).  And while things have changed
some over the years, there are a number of things that should also
still be considered.  Such as:

1) As a programmer or company, would I rather have hundreds of more
   customers buy the product, or would I rather have them decide not
   to buy it because they would rather not buy yet another drive.

   Along with this, it needs to be remembered that there are
   limitations to the number of drives which can be put in a system,
   and the size of the drives.  So if the person uses the system for
   one thing but happens to want to install UT to stay sane, but
   cannot add the disk...no sale.

   And yes, 10% seems like nothing.  But remember that it can add up.

2) With decent install/packaging tools, very little developer time
   should be needed.  I have lost track of the number of times I have
   programmed shell, BAT or scripts to make simple decisions, such as
   does the license key allow installing options X, Y or Z.  Or
   comparing the host processor against the license key, or countless
   other things.  Shoot, we did stuff like this back in the DOS and
   Win31, and it only took one person about an hour to add the logic
   the first time.  For that matter, I have dozens of shell scripts
   which pick up on processor, OS and OS release in which took me less
   time to write the decision logic than it is taking me to write this
   message.

   Best of all, OS/X uses a BSD *NIX core, so if Apple does their job,
   something simple like a `uname -m` and a case statement should do
   the trick.

As for build stuff, that should practically be a no-brainer there as
well.

Oh, and just to be sure folks know, I have no problem with shipping
multiple binaries which are selectively installed.  My problem is
bloating executables by making contain everything for multiple
architectures.

- Doug

Quoting Guy Hutchison (ghutchis at gmail.com):
> On 6/22/05, Douglas Wade Needham <cinnion at ka8zrt.com> wrote:
> > Suggestion on supporting the multiple Mac platforms (coming from my
> > experience of working with a similar setup on an embedded environment
> > on nearly identical PPC and x86 processors).  Rather than
> > shipping a UT executable which is multi-platform, why not just have
> > the installer detect the HW and install either a PPC or x86 binary.
> > It will save some disk and probably have other positive performance
> > impacts as well.
> 
> Doug, methinks you are optimizing a cheap resource (disk space) in
> favor of an expensive one (programmer time).  The disk space consumed
> by the UT2004 binaries is less than 10% of the total install, so
> shipping every binary you have wouldn't make it significantly bigger. 
> Also, the Mac has support for fat binaries courtesy of the 68k
> migration, so there may be built-in platform support for shipping both
> vs. writing (and testing) a more complicated installer...