On Wed, Oct 04, 2006 at 07:12:49PM +0200, Brandon Peirce wrote:
>
> For the "64-bit upgrade", I guess I have to choose one of the two x86_64
> Clfs books. Is the multilib build significantly more complicated for a
> cross-
> compiling newbie? Is the "pure 64" system significantly more limited in
> everyday
> use (difficulties compiling CBLFS packages, binary-only packages not
> available)?
>
Hi Brandon,
as one of the proponents of pure64, I regard it as easier ;) For
people who compile most things from source, it means you don't have
to care if a package is going to install into /lib or /lib64 [ no
longer quite true, the version of popt in BLFS likes lib64 on
certain 64-bit arches - but then the same is true if you build it as
32-bit on multilib! ].
In general, both pure64 and multilib on x86_64 will need attention
in the same packages (typically, update config.guess and config.sub,
sometimes pass -fPIC). However, there is probably a little more
breakage in pure64 (I've seen it in the past in abiword, I'm possibly
seeing it at the moment in audacious and somewhere in the printing
function, but that remains to be debugged).
Certainly, you won't find binaries for pure64. AFAIK for clfs this
mostly only affects browser plugins (flash, java, realplayer, ...) and
perhaps some proprietary codecs (if you had other proprietary apps,
they probably wouldn't work on anything except a specific version of
RH).
On the positive side, in pure64 you build things once, you don't
have to take steps to ensure that libtool tries to use the correct
files, and you don't have to get into the joys of multiple gtk2/pango
directories. Plus you don't get the fun of persuading jpeglib to
build as 32-bit on x86_64 (search for the configury patch if you go
that way).
The thing you really need to do in multilib is work out what _you_
want for normal everyday use. From that, you can then work out what
should be 64-bit (on x86_64, that will normally be most of it) and
what should be 32. Then, you can determine the dependencies, and
which packages you need to build in both sizes. The first time,
expect to end up with some libraries in the wrong directory, and
problems where a program (rather than a library) needs to be in both
sizes (that's what the multiarch wrapper is for), also the correct
PKG_CONFIG_PATH.
Programs I think might need the wrapper include freetype-config,
fc-*, gdk-pixbuf-*, gtk-query-immodules-2.0, pango-querymodules. My
current multilib desktop development is on ppc64 on a version of
clfs predating the wrapper, so I'm not up to speed on multilib x86_64.
> For the i{4,5}86 build, I guess I have to use the Intel/AMD x86 book. Is
> that
> the same whether I start from i686 or x86_64? (I guess that's another way
> of
> saying I'm not clear whether the choice of book depends solely on the target
> or is determined by the host?).
Yes, the target determines which version of the book, all you
change is the CLFS_HOST variable. I've no experience of non-native
builds for i{4,5}86, but I think somebody had issues a month or two
back building for i586, it's probably in the archives with the fix.
Ken
--
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
