Re: More on 32bit/64bit ABIs under Linux

[hjl@lucon.org (H.J. Lu)]

> 
> > 
> > On Apr 21, 1999, hjl@lucon.org (H.J. Lu) wrote:
> > 
> > > 3. Add "-prefix /ABI32" to ld. It adds the prefix, "/ABI32" to all
> > > search paths if appropriate.
> > 
> > How do you decide the `if appropriate' part?  Would the user be forced
> > to install libraries of a given ABI into a particular tree?  I
> > wouldn't appreciate such a policy.  It's might be ok for libraries
> > included in a distribution, but not for user-installed ones.  And
> > then, for the distribution case, gcc can be taught which linker flags
> > to use when given a -mabi switch.
> 
> One thing I don't like on the /ABI32 approach is that unless you try very
> hard, a lot of 32bit binaries compiled on the 64bit system will differ from
> those compiled on the 32bit system, and IMHO this is a pain. You'll have the
> /ABI32 stuck all around you RPATHs and stuff like that. But if some

Do we want to encourage people to use 64bit ABI on 64bit machines?

> developer has a powerful 64bit machine which can run natively the 32bit
> binaries, I bet he'll be using it for development of the 32bit binaries as
> well, but would like that it makes no difference in how do they look like.

That is why we have to modify the linker to support /ABI32.
/ABI32 is used by the linker to find the right libraries. I have
proposal on soname so that we can put both 32bit and 64bit libraries
in the normal places.

> Now, with the exception of Alpha, which is 64bit only in Linux, so is not
> relevant to this, no Linux port has the 64bit userland set up yet, so IMHO
> it does not matter if you choose paths different to /lib etc. (and if the
> linker autodetection of lib ABI is implemented, it will not really matter,

You don't want to complicat things. For libfoo, linker will search for
libfoo.so and libfoo.a only. You better put the 32bit versions in /ABI32
even if they are just symlinks to /usr/lib.

> as at least the common paths /usr/lib, /usr/local/lib, /usr/X11R6/lib and
> /lib will be handled in the specs files, so it will be absolutely
> transparent to those source compilations unless it has some custom library
> search paths, which only a few projects do) for 64bit ABI and such choice
> does not yet say which ABI is the default.
> 
> > 
> > > 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.
> > 
> > Wouldn't it be better to extend ld.so so that one could have a
> > different .conf file for a different ABI.  For example,
> > /ABI32/etc/ld.so.conf, or /etc/ld.so.conf-ABI32 ?
> 
> I have a modified ldconfig which handles all of this from within one
> ld.so.conf (attached bellow).
> It automatically detects 32bit and 64bit ABI on SPARC, but support for other
> architectures can be easily added. In addition to this, it has a notion of
> libraries optimized for some particular CPU which mean requirement that a
> chip is at least XY or later in the series.
> To find out this, there can be either automatic test (e.g. 32bit binaries
> requiring some instructions from the 64bit SPARC instruction set have a
> special EM_), in some cases this is not possible. But the user can
> specify/override this in ld.so.conf for all the libraries in some directory.
> e.g. ld.so.conf can look like this on SPARC:
> /usr/X11R6/lib
> /usr/X11R6/lib64
> /usr/lib
> /usr/lib64
> /lib/sparcv9=sparcv9
> /lib/sparcv8=sparcv8
> /lib
> /lib64
> 
> or for Intel it could look like this:
> /usr/X11R6/lib
> /usr/X11R6/lib64
> /usr/lib
> /usr/lib64
> /lib/i786=i786
> /lib/i686=i686
> /lib/i585=i586
> /lib/i486=i486
> /lib
> /lib64
> 
> so you could have both Merced and ia32 libraries on the same system,
> plus optimized libc for different CPUs and still be able to take the disk
> from your i786, put it into i386 and it would run.

It is ok for the runtime linker. But it will have problems for package
compilation and installation. For example,  64bit XFree86 will be a
mess even if I don't want the 32bit XFree86 on my 64bit machine.

H.J.