Re: PROPOSED: 32/64 bit coexistance

[Oliver Paukstadt <pstadt@stud.fh-heilbronn.de>]

On Mon, 17 Sep 2001, George Kraft IV wrote:

> > > While this naming conventions seems quite obvious and natural it
> > > is not backward compatible: existing 32bit applications will
> > > install and search their 32bit shared libs in /lib which will
> > > only contain 64bit libs. A symbolic link or renaming to  /lib ->
> > > /lib32 will conflict with installed 64bit applications on the
> > > system. This is clearly not an issue for the loader, that will
> > > be able to properly select the library to load from, but will be an
> > > issue for all existing 32bit applications and their install scripts
> > > and the like, not knowing about the hybrid nature of a 32/64bit
I don't agree with this.

First we have two loaders both residing in /lib, a 32 bit and a 64 bit
loader.
On Linux for zSeries this are /lib/ld.so.1 for 32 bit architectures and
/lib/ld64.so.1 for the 64 bit architectures.
They know where their suitable libraries reside.
When I built the first rough emulation for our ThinkBlue/64 Distribution,
the first real 64 bit distribution for Linux for zSeries, I moved all
emulation libraries to /emu31, including a special ld.so.conf as well.

The second problem is about packaging. In my opinion it is a task for the
package manager to find the right place for the shared libraries. Lets
talk about RPM, thats the only on I have experiences with.
All packages would have the /lib and /usr/lib (are we talking about
/usr/lib as well ?) pathes in it, because the natural architecture (imho)
should always reside in plain pathes without numbers. Only compatibility
architectures should reside in /libXX and /usr/libXX
Then it is a task of the package-manager to detect compatibility
architectures and relocate the files for /lib to /lib32 and /usr/lib to
/usr/lib32.

I don't know if it makes sense to build 128 bit CPUs, but then we would
have /lib for the native 128 bit architecture, /lib64 for the 64 bit
compatibility architecture and /lib32 for the 32 bit compatibility
architecture. With your appraoch you than need /lib pointing to /lib32 and
/lib64. Don't be to shortsighted.

I don't know if there are RPM or RedHat people on the list, because there
are no redhat people among the explict named recipients. We should talk to
the rpm people because I think if the package manager could solve our
problem, we should solve the problem in a clean way and not have /lib
pointing to /lib32 or /lib64 depending on an existant compatibility
architecture or not. Great standard. ;-/
If there is an existant compatibility architecture but you don't want any
programms using the compatibility on your system, /lib points to an empty
/lib32 directory ??

Another point is that you need a ldconfig and a ldconfig32 or a unified
ldconfig managaing the compatibility architectures as well. The same is
with ldd, ld.so.conf and so on. In your suggestion we get an ldconfig and
an ldconfig64. I think with this analogy it should be clear which
version gets the numbers and which gets the plain name. A special ldconfig
for the native architecture is not intuitional.

And most distributors say "one source package for all architectures" so
you need to use macros in your rpm spec file and especially in your %post
and %pre scripts because on 64 bit architectures /lib is /lib64 and on 32
bit architectures it is /lib or /lib32.
With macros %{LDCONFIG} and %{LIB} evaluated during install time of
package this problem should be solved.

In my opinion compatibility architectures are only for very rare special
cases. The target is to have only native software. With this target a 
/lib -> /lib32 is not acceptable.
In my opinion it could only be a temporary solution until a
software seller could provide a native package for that architecture.
And if the source (and in my opinion the resulting code as well) is good,
there is no problem porting a real big project to a 64 Bit architecture in
a quarter of a year.
And if a company is not able to provide a 64 bit version of it's software
they should at least be able to repackage it correct for the hybrid nature
of 32/64 bit systems.

I don't want a /lib -> /lib32 path because it seems the easier way.
In my opinion we will get lots of trouble with this later on.
(rembering IRIX and it's compatiility architectures ..)

Maybe it is the most conveniant way for SuSE and IBM, but I think we 
should talk to the RPM (RedHat) people because they maintain the package
manager. 
SuSE still uses a rather outdated rpm 3.0.6 in it actual distribution and
(I think) the spec files of their packages are *very* ugly. 
I don't think we should introduce a /lib link to the compatibility
architecture only because it is the most conveniant way for a outdated
package manager.

Maybe the IBM should have experiences with 64/32 hybrid systems or is AIX
only a natural system? What about the AIX/Linux compatibilty layer? How do
you solve that problem? Is /lib pointing to /libLinux32 on that Systems?

"Remembering the 16 bit compatibility mode for Win95"  *urg*

Greetings
Oliver Paukstadt

+++LINUX++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++Manchmal stehe ich sogar nachts auf und installiere mir eins....+++++++
+++ pstadt@stud.fh-heilbronn.de +++ oliver.paukstadt@millenux.com ++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
           Linux without Limits - http://linux.zSeries.org/