[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upcoming Debian multiarch support (amd64, sparc64, s390x,mips64) [affects sarge slightly]



On Mon, Jan 12, 2004 at 03:22:40PM +0100, Julian Mehnle wrote:
> Josselin Mouette wrote:
> > Le dim 11/01/2004 à 08:00, Goswin von Brederlow a écrit :
> > > The currently implemented idea was to rename the amd64 package of
> > > libfoobar to lib64foobar and have amd64 binary packages depend on that
> > > name instead. libfoobar.so goes to /lib and lib64foobar.so to
> > > /lib64. That works so far.
> >
> > Am I the only one to think the whole /lib64 idea is fundamentally
> > broken? We already have ia64 without this. We can build a very similar
> > system for amd64, introducing a new arch. Then, ship a few 32-bit
> > compatibility libraries for 32-bit proprietary software.
> 
> Yes, I also think the /lib64 idea is fundamentally broken.

Having actually used it, for both PowerPC64 and MIPS64, I disagree that
/lib64 is broken.  I think that Goswin either misspoke above about
lib64foobar.so or has a very bad idea - it's suppose to be
/lib/libfoobar.so.1 in libfoobar1, and /lib64/libfoobar.so.1 in package
lib64foobar1 (or whatever you feel like calling it).

There are always good reasons to build packages on a different ABI. 
When I did this for MIPS, we did (are doing) a base system of N32,
complete O32 libraries for compatibility with existing applications,
and complete N64 libraries for large applications needing the memory
space.

However, we (after much discussion) did the compatibility libraries as
separate packages from our existing o32 MIPS architecture.  I still
think that is a wiser way to go than attempting to mix and match from
different architectures.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



Reply to: