[mythtv] Compiling on AMD64

[Axel Thimm]

On Thu, Feb 02, 2006 at 04:00:40PM -0500, Isaac Richards wrote:
> On Thursday 02 February 2006 15:53, Colin Guthrie wrote:
> > Isaac Richards wrote:
> > > IMO, putting the native libraries of a system in anything other than /lib
> > > is completely wacky.
> >
> > I kinda agree with you, but I think the reasoning *for* doing it is
> > fairly good too as it means you can co-install 32 and 64 bit libs on the
> > same system.
> >
> > The alternative would be to install all the 32 bit libs in e.g. /lib32.
> > I actually like this better, but it means that a gradual transition to
> > 64bit is much more complex and you can't just install the 32-bit
> > versions from your distro without specifically building the 32-bit libs
> > for a 64-bit filesystem layout which is a bit wacky in itself!
> >
> > So I guess it kinda makes sense in that respect.
> 
> Why would you need a gradual transition to 64-bit?  I don't have any 32 bit 
> libraries on my system.  All my 64-bit libraries are in 'lib'.  Install 
> compatability libraries elsewhere, instead of forcing native ones into odd 
> locations.

The idea of x86_64's i386 backwards compatibility is that you can use
the existing i386 bits and packages. And that only makes sense if you
don't need to rebuilding them. Like from ISVs that package up a
backup-solutions, antivirus etc only for the i386 cousin. Also a lot
of software projects don't build properly under x86_64 yet. Some time
back openoffice was only buildable under 32 bits, currently nx/freenx
comes to mind, and mythtv 0.18 also.  Before Jarod's backport of some
64 bit fixes x86_64 Fedora users could simply install into their
system the i386 packages w/o having to rebuild and relocate the
contents to /lib32 or similar.

Debian and therefore Ubuntu suffer from one of the infinite debates on
how to solve this better than all the rest. Debian's suggestion is to
use /lib/i386-linux and /lib/x86_64-linux.

http://www.linuxbase.org/futures/ideas/multiarch/#proposal

That's a pure solution and the right thing to target in the future,
but today's compatibility packages already have stolen /lib, and we
need to deal with that first.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20060203/8da3125c/attachment-0001.pgp