[openfabrics-ewg] 32-bit build for ppc64 is required

[Michael S. Tsirkin]

> Quoting Stefan Roscher <ossrosch at linux.vnet.ibm.com>:
> Subject: Re: 32-bit build for ppc64 is required
> 
> On Wednesday 14 February 2007 14:29, Michael S. Tsirkin wrote:
> > > Quoting Stefan Roscher <ossrosch at linux.vnet.ibm.com>:
> > > Subject: 32-bit build for ppc64 is required
> > > 
> > > Hi,
> > > 
> > > after building the latest ofed build package we recognized that on PPC64 only
> > > 64-bit libaries were build.
> > > Because we have customers using older userpace apllications which are
> > > certified for 32-bit we think additional 32bit support is a requirement for 64bit builds.
> > > 
> > > If OFED 1.2 supports 32 bit on ppc64, we have to change the install
> > > directory.I would suggest to install 32-bit binaries into
> > > /usr/local/ofed/bin32 directory. So no changes on current naming conventions
> > > has to be done.The libaries are installed in the /usr/local/ofed/lib directory.
> > 
> > The standard practice is to install 64 bit libraries under prefix/lib64
> > and 32 bit libraries under prefix/lib. Why would PPC64 be any different?
> 
> I think you missunderstand my post. The directory for 32/64bit libaries
> shouldbe prefix/lib and prefix/lib64 respectively. 
> But current ofed1.2 I saw only prefix/lib64 directory, ie 64bit libs only.  

Well, this is not by design: AFAIK on x86_64 both types of libraries
are installed.

> > I do not think we need 32 bit binaries at all, and there's no other package
> > I'm aware of that uses "bin32".
> 
> We have customers that still use 32-bit userspace applications. 
> It would be beneficial for them if they can obtain 32bit libs and execs from
> ofed1.2 in order to run their applications without recompiling them, because
> for some 32-bit applications recompiling is not an option.

32 bit libraries are needed for users to run 32 applications.

But I still do not see how installing 32 bit binaries alongside the 64
bit ones is useful, and I do not think other packages provide this option,
so maybe we shouldn't, either.

-- 
MST