This is the mail archive of the
mailing list for the GCC project.
re: Multiplatform binary generation
- From: Dan Kegel <dank at kegel dot com>
- To: deploy dot kde at seznam dot cz, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Fri, 14 May 2004 08:54:26 -0700
- Subject: re: Multiplatform binary generation
I am working on research project to implement executable binary
> for all major linux desktop platforms. The file is named .dlx
> and should contain merged executables for Linux on:
IA-32 - 686
IA-32 - P4
IA-32 - Athlon XP
x86-64 - AMD64/Opteron
x86-64 - Intel IA-32e
Point is that after installing desktop software, installer will go trough
> dlx files and create a native executables out of it by stripping-out
> everything else. ...
> like gcc to developer. It will compile sources for all platforms mentioned,
The main project is to create compiler for .dlx "platform" that will "look"
and then merge binaries to .dlx file. ...
I would like to hear any your sugestions or comments before I spent months developing it.
(This is similar to the 'fat binary' approach.
except that in fat binaries in the past, the OS directly
supported them, and ran the right fork of the file.)
I would advise against this. Generally, people don't want to
download the extra bits, and as Dave Korn says, separate binaries
really aren't that hard to deal with.
(BTW, if you're actually trying to build an application for N
different targets, you might find http://kegel.com/crosstool helpful in setting
up a uniform build environment across multiple targets.)
A more important problem to solve, I think, would be to achieve
binary compatibility *within* a platform type! You are aware,
aren't you, that packages built for i686-linux don't run
on all i686-linux systems because of subtle differences in
system libraries etc? The LSB project is working on solving this.
You might consider joining their team if you want to help make
distributing applications easier.
LSB 2.0 (coming soon) will support C++ (much easier now that
gcc-3.3.x, which actually has a C++ ABI, is in wide use).
The next step might be to add X.
LSB won't be able to add KDE or Gnome until they define ABIs.
Gnome has started dicussing this:
I don't know if KDE has yet.
This is now a bit off topic. Followups to /dev/tinfoilhat, I suppose...
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change