[mojosetup] First shot at documentation...

[Ryan C. Gordon]

> I'd want to distribute a single setup, which would be a 32 bit binary as
> it's basis. On my debian sid x64 machine, the 32 bit binary starts fine
> and goes to the stdio GUI. I'd rather avoid putting a statically linked
> Gtk2 in, and it turns out sid does not have 32 bit compatibility Gtk 2
> library installed. However, if the initial 32 bit binary would somehow
> relay to a 64 bit binary when the platform is right, that might solve
> the problem fairly nicely?

I just committed a workaround for this in svn revision #301, but I'm not 
happy with it, so I might back it out of Subversion. Here's how it 
works, though:

- Installer process starts.
- If it see the --nobinswitch command line or MOJOSETUP_NOBINSWITCH 
environment variable, it goes on as usual. Otherwise...
- It sets an environment variable: MOJOSETUP_NOBINSWITCH=1
- It looks for an arch/ directory in the Base Archive, and for each file 
in there, it copies it to a temp directory and tries to exec() it.
- If any succeed, we have replaced the process, and the new one sees the 
NOBINSWITCH thing.
- GUI initializes, etc...

So you can build your installer on x86 and amd64, put both arch's GUI 
plugins in the Base Archive (name them whatever you like, so they don't 
conflict) and the amd64 installer binary into arch...zip it all up and 
append it to the 32-bit installer binary.

The 32-bit binary will make an earnest attempt to replace itself with 
the 64-bit one, but if it fails for any reason (no 64-bit support or 
whatever), it'll continue on, trying the 32-bit GTK+ plugins, etc.

You need to set the CMake option: MOJOSETUP_MULTIARCH=TRUE in at least 
the 32-bit binary, or it won't even look at the arch/ directory 
(completely #ifdef'd out). This is off by default, and flagged as an 
"advanced" option, so it won't show up in ccmake by default.

In practice, this will catch most problem scenarios, but it's an ugly 
solution, and it won't help you with amd64 users that have disabled 
32-bit support in the kernel (since the installer won't start), and it 
won't help you with, say, PowerPC users. The increase in download size, 
however, is pretty tiny, since the amd64 binary can be compressed in the 
.zip file.

I'd love someone to extend the ELF format so that it supports "fat" 
binaries, like Apple's Mach-O format does for the PowerPC/Intel 
"Universal" binaries...but that would require coordination and support 
at several points in the system software stack.

Depending on your needs, you might be better off wrapping the installer 
in makeself or shipping multiple installers, but these all have 
drawbacks, too. Maybe you just need to require amd64 users that want to 
run 32-bit binaries to supply a more robust environment or suffer the 
wrath of the stdio UI. This solution feels extremely dirty to me.

--ryan.