> > I understand that some programs have "issues" with 64-bit systems.
>
> What issues? I've been running 64bit systems since 2005 with ppc64,
> sparc64, and x86_64. The only issues you will encounter is with
> precompiled binaries which aren't 64bit and require certain libraries
> such as a specific libstdc++ version. Building everything from source
> hasn't been an issue since most developers have matured the source.

Ahh, that's good to know.  Guess I was still seeing "old news".  Since
my (B)LFS-7.2 I've been able to replace the Oracle JRE binary with
OpenJDK, thanks to Pierre, and Flash with Shumway now that I can support
Firefox-35.  Except for some in the kernel I guess, I'm at the moment
binary-blob free.  I've been hoping for that for a long time, and hope
to be able to keep that up.

> >How common is this?
> Building a 64 bit system is common. Encountering a binary which
> requires specific libraries can be common if you do it all the time. I
> can remember java, acrobat, wine and some other binaries I can't
> remember right now.

So you're suggesting I go pure 64?  X drivers all OK with 64?

> > How does one know how to plan for the "BLFS" stage?
> We build a few systems and figure out what is exactly needed. If you
> stick with CLFS multilib, use the cblfs.clfs.org wiki for a guide and
> use BLFS with updated packages. You'll need the multiarch wrapper and
> most packages will require --libdir=/usr/lib64 for 64bit along with
> PKG_CONFIG_PATH and USE_ARCH variables.
>
> Keep it simple, if you don't need multilib, don't do it. It's a
> headache.

So if I go pure 64, then all the headers and libraries all work out
automagically, and I can pretty much ignore the differences?

> > After an x86-64 system is created, and would be the host for future
> > development, then what?  Presumably the next system doesn't need to
> > be cross-compiled.  Can one use the regular LFS book?  I just want
> > to know what it "means" to make the shift.
>
> You can build CLFS through cross-tools and temp-system, and then
> follow LFS book after chroot or by the boot method without issues.

I think maybe we're talking about different things.  If I make a pure 64
CLFS system, then in a couple years found some reason to need an update,
do I have to go back to make a new CLFS, or as I asked above, does
everything work out and I can follow the LFS book again?

> With CLFS, we include graphite loop optimization support, where LFS
> doesn't. If you require that, then you need to build CLFS in chroot or
> by boot method through GCC, then you can use LFS.

Graphite loop?  Wozzat?  Never heard of that before, being pure LFS-32.
Why would I require that?

Sounds like MAYBE that last clause answers my queston in the last
paragraph?

> If your current machine is multilib, then you can't blindly follow LFS

Just LFS-7.2 with updated Firefox & OpenJDK.

> instructions. You have to keep the multilib instructions in your
> build. LFS isn't multilib. Even though you don't need to cross-
> compile, you still need the multilib instructions.

But going from where I am up to pure 64, I wouldn't?
-- 
Paul Rogers
[email protected]
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)

        

-- 
http://www.fastmail.com - The professional email service

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to