Selon Ken Moffat <[email protected]>:

> On 10 May 2010 07:41, Gilles Espinasse <[email protected]> wrote:
> >
> > ----- Original Message -----
> > From: "Ken Moffat" <[email protected]>
> > To: "LFS Developers Mailinglist" <[email protected]>
> > Sent: Sunday, May 09, 2010 10:12 PM
> > Subject: Re: gmp note (#2648)
> >
> >
> >> >
> >>
> >>  For x86_64-capable CPUs (pedantically, I don't think this is an issue on
> >> other 64-bit-capable architectures) I see no benefit in specifying
> > '--build'..
> >> ABI=32 is more appropriate.
> >>
> > Should be the same on ppc and sparc 64-bits cpu with 32-bits userland.
> > I don't have a pcc64 and my sparc64 build is broken actually.
>
>  My ppc64 is part way through building LFS-6.6 for my ibook (I managed
> to get a new battery, so I'm hoping to give it a less ancient system).  The
> ibook is a 'G4', my reading is that the binaries will _probably_ work.  I
> grant that a G3 (750) would get different native code.  But that's a
> build-for-another-machine comment.
>
yes, on my imac G3, without --build=ppc-linux, resulting configuration is
using ABI="32"
      CC="gcc -std=gnu99"
      CFLAGS="-O2 -pedantic -mpowerpc -mcpu=750"
      CPPFLAGS=""
      MPN_PATH=" powerpc32/750 powerpc32 generic"

With --build=ppc-linux
using ABI="32"
      CC="gcc -std=gnu99"
      CFLAGS="-O2 -pedantic -mpowerpc"
      CPPFLAGS=""
      MPN_PATH=" powerpc32 generic"


>  What I know for certain is that my ppc64 [ biarch toolchain, 64-bit
> kernel, everything else 32-bit, with a 32-bit default ] didn't need any
> ABI= override even though I seem to pass CFLAGS=-O2.
>
This added first for sparc64 as we build a 32-bits userspace

> >>  Is this the only place in the current book where following the
> >> instructions and building on recent i686 produces binaries that
> >> do not run on i486 ?
> >>
> > Parsing our entire build tree with analyse-x86.sh (curious name for a perl
> > script), here are the first results
> >
> > kil, ps, free, top, uptime, vmstat, w belong to the same procps package.
> > There is a problem there.
>
>  Thanks for that.  Unfortunately, I'm starting to feel less convinced
> about the merit of mentioning this for the book as part of this ticket..
> Adding notes *all_over* the book for a situation that I'm still not sure
> we *support* seems wrong [ the notes jump out of the page, as they
> are meant to ].
>
I understand this is near the limit of LFS goals.

I will try to rewrite analyse-x86, so that it give a more usable result when
checking a list of binaries. Once that is made, that would probably worth adding
a few lines to optimizations hint.


Gilles
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to