On Wed, Jan 17, 2007 at 05:57:52AM -0800, Jonathan Davis wrote:
> >
> >If I want to build a 64bit Linux base which will be happy running most
> >of the main desktop (inc. OOo) and some server apps (LAMP/SVN/SSH)
> >should I build a pure 64bit or a multilib CLFS system?
> >
> 
> Personally, I think that the number one reason to go with multilib is
> Wine.  Since Wine is going to be running 32-bit binaries, it needs all
> of the appropriate 32-bit libraries.  Other programs that would need
> 32-bit libraries are non-OSS stuff like RealPlayer or Adobe/Macromedia
> Flash Player.  Basically anything that you can't build yourself is
> going to be a 32-bit binary and will thus need 32-bit support.
> 
 What is this sudden eruption of people mentioning Wine of the *lfs
lists ?  I thought it was mostly a minority interest, except for
gamers and corporations ;-)

> Of course, you can choose not to use Wine, or RealPlayer, or anything
> that uses non-OSS code.  At that point, you're generally okay with
> pure 64-bit.  However, some packages don't yet work properly in 64-bit
> land.  I don't know if it's been fixed, but it has been reported to
> this list that the Gimp doesn't work properly in 64-bit mode - some
> problem having to do with 32-bit brushes.

 Correction - I reported that, it _only_ applies on ppc64.  What may
have misled you is that my multilib buildscripts for x86_64 and ppc64
do the same thing (to try to keep my sanity), so I currently have it
as 32-bit on both.  On pure64 x86_64-64 it works fine.

>  However, OpenSUSE (and
> probably the other 64-bit distros as well) runs a 64-bit verion of the
> Gimp, so even if the main Gimp tree hasn't fixed it yet, perhaps the
> fixed src can be taken from a distro's rpm or deb file.
> 
> In any case, you basically need to decide what you want your system to
> be able to do.  If some of those things require 32-bit support, then
> you're going to need a multilib system.  Once you've decided which
> packages are going to need to be multilib (or just 32-bit), you can
> determine which other packages they need as dependencies and thus must
> be multilib.
> 
> Perhaps a list of programs that need multilib support would be nice,
> but the ones that I'm aware of at the moment are Wine, RealPlayer,
> Macromedia FlashPlayer, Adobe's Acroread, and any other non-OSS
> program that you might try and run (I'm unaware of any being
> distributed as 64-bit binaries).  Unless you know of a specific
> instance of a program not functioning in 64-bit mode (like the Gimp),
> I wouldn't worry much about that.  Even if you do find one, there's
> probably a good chance that you can just get the source from a
> distribution's files.
> 
> The two things that I'm not clear on, are whether or not 32-bit
> mozilla plugins (like Java JDK) will function in 64-bit browsers and
> whether or not media codecs will work in 64-bit media players.

 These player 'plugins' can be funny things - certainly RealPlayer
(32-bit) works from 64-bit konqueror on ppc64.  But, it is linked
against 32-bit X and toolkit libs so it needs to be on multilib.
>  I
> haven't gotten far enough with my CBLFS system to say yay or nay.  I
> have heard that they don't work in 64-bit land, but my OpenSUSE
> installation is able to do both of those in 64-bit land
> somehow-or-other.
> 
> Well, hopefully that was fairly insightful without being too
> dreadfully long.  Welcome to CLFS!
> 
 On other things mentioned: I'm running my server as pure64.  There
was a small glitch in apache (one of the modules refused to load),
but I only need a minimal apache so I commented it out of the conf.
That was using the blfs instructions, I haven't looked at cblfs
about it.

 OOo isn't something I'd willingly use - I know it is supposed to
build as 64-bit now, but I've no idea whether that means multilib or
pure64 or 'on a clear day, with the wind in the right direction,
with these sixteen specific versions of dependant applications'.

 SVN (as a client) and ssh are fine on pure64.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
_______________________________________________
Clfs-support mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support

Reply via email to