More on 32bit/64bit ABIs under Linux

[hjl at lucon dot org (H.J. Lu)]

As Linux moves to new platforms with both 32bit and 64bit ABIs, we now
face the problem to support 2 different ABIs at the same time. There
are different levels of support for 2 ABIs. We need to define our
goals first. There are 2 categories of approaches:

1. Choose 64bit as the  native ABI for the platform, support both
compile and run-time environments for the native ABI. For the 32bit ABI,
only the run-time environment is provided by default. The compile
environment for the 32bit ABI is implemented as a cross-compile system.

  Pros:
    A. Minimal change to the existing 64bit clean source code base.
    B. Encourage migration to the 64bit ABI.

  Cons:
    A. If the source code is not 64bit clean and it is very hard to
    clean up due to various reasons, you have to compile it on the
    32bit platform or cross-compile it on the new platform. For a
    complex package which depends on many other 32bit packages, it may
    be a problem.
    B. It is not easy to install the precompiled 32bit binary package
    on the platform with the 64bit native ABI. If the package has its
    own 32bit development and/or run-time systems, it makes things even
    worse.

2. Both 32bit and 64bit ABIs are both native for the platform, support
both compile and run-time environments for 2 ABIs. The compile and
run-time environments can be made backward compatible with the 32bit
ABI.

  Pros:
    A. No change to the existing 32bit source code.
    B. Easy to install, most if not all, existing 32bit binary packages,
    including those with their own 32bit development and/or run-time
    systems.

  Cons:
    A. May require massive change to the existing source code base
    to use the 64bit ABI even if the source code is 64bit clean. Since
    most of the Linux softwares are available in the source form, it
    may benefit mostly commercial ISVs who want to keep using the 32bit
    ABI on the 64bit platform.
    B. Delay migration to the 64bit ABI.
   
Personally I prefer #1. But it will be a problem for those commercial
ISVs whose sources are not 64bit clean or they don't want to make 2
versions of the same product due to support and test. Whatever we
do, we have to decide now since the decision we make may affect many
Linux software developer, commercial or non-commercial. The earlier
they know, the better they can prepare.

The more I think about it, the more I think we should choose #1.
To solve the problems of #1, we can do

1. Make the 64bit ABI as the native ABI.
2. Put all 32bit ABI related files under a directory, say /ABI32. That
is we have

/ABI32
/ABI32/lib
/ABI32/usr/lib
/ABI32/usr/local/lib
/ABI32/usr/X11R6/lib
.....

3. Add "-prefix /ABI32" to ld. It adds the prefix, "/ABI32" to all
search paths if appropriate.

4. Add "-prefix /ABI32" to gcc.c. It passes "-prefix /ABI32" to ld.

5. All 32bit binaries are built and installed on the 64bit machine with

# CC="gcc -prefix /ABI32" .../configure --prefix=/foo/bar
# make
# make install

To use the newly installed 32bit libraries on the 64bit machine for the
32bit ABI, we have to make necessary symlinks to /ABI32 so that
"gcc -prefix /ABI32" will find them.

6. Modify the package problem to install the 32bit binary packages:

	1. Install everything under /.
	2. Make necessary symlinks to /ABI32.

In that way,

1. We can build the 32bit ABI binaries on the 64bit machine which will
run on both 32bit and 64bit machines. The only major change is to use
"gcc -prefix /ABI32" for cc.

2. We can install the existing 32bit binary packages.

The main drawback is it may not be easy to install both 32bit and 64bit
binaries of the same software. But it is not impossible:

1. Install the 64bit binaries under /.

2. Install the 32bit binaries under /ABI32.

3. Modified ldconfig.c to append /ABI32 to each entry in
/etc/ld.so.conf if necessary and add them to /etc/ld.so.cache.

4. Make sure the 32bit run-time linker will find the shared objects
under /ABI32.

What do you think?

Thanks.


-- 
H.J. Lu (hjl@gnu.org)