Em 07-10-2015 19:26, William Harrington escreveu:
> On Oct 7, 2015, at 15:47, Fernando de Oliveira <[email protected]>
wrote:
>>
>> I had some doubt, reading the doc pointed out by William, if it should
>> be host, not build that should be used in configure, but decided to
>> trust William's, much better and longer experience:
>>
http://lists.linuxfromscratch.org/pipermail/blfs-support/2015-October/077151.html
Replaced by a more economic form.
CONFIGURE="./configure \
--prefix=/usr \
--enable-cxx \
--disable-static \
--build=`uname -m`-unknown-linux-gnu \
--docdir=/usr/share/doc/${PACKAGE}" &&
>
> Hello,
Thanks for your reply.
> The three options: the machine you are building on (build), the
> machine that you are building for (host), and the machine that we will
> produce code for (target). Specify these with --build=, --host=, and
> --target=.
So, I understood almost this.
Saw the other thread and that made me try your suggestions, as I
sometimes copy from one machine to the other which may have a different
processor (AMD is something I intend to buy) or may even be virtual
(qemu, virtual box or vmplayer).
Had used the first suggestion, with
cp -v config{fsf,}.guess &&
cp -v config{fsf,}.sub &&
I'm trying this also, because I know LFS needs as many as possible
discussions, in order to address these problems.
> Since the tool chain is with the build machine, then
> x86_64-unknown-linux-gnu (for example) will be the triplet used. Since
> in LFS, the build machine is most likely the target machine, it will
> all be native. If the target machine is not the build machine, then
> steps need to occur to make sure the binaries created will run on the
> target machine. Make a generic toolchain, optimize only for the
> target, or have a combination of march and mtune optimizations.
I eventually will use a different host for the system, but target will
always be the same as host.
>
> It is problematic to build for a target when the build machine cannot
> run the binaries created for the target. Target has a newer CPU than
> target CPU. Target is a different architecture than the build machine.
> The target machine has an instruction set that is not the same as the
> build machine.
No, I'm not considering this. At the moment: build=host=target.
>
> Sincerely,
>
> William Harrington
>
I would like to be sure, so did some comparisons, yesterday night.
used one, none or both following switche in configure
--build=`uname -m`-unknown-linux-gnu \
--host=`uname -m`-unknown-linux-gnu \
Both:
configure: summary of build options:
Version: GNU MP 6.0.0
Host type: x86_64-unknown-linux-gnu
ABI: 64
Install prefix: /usr
Compiler: gcc
Static libraries: no
Shared libraries: yes
Only build:
configure: summary of build options:
Version: GNU MP 6.0.0
Host type: x86_64-unknown-linux-gnu
ABI: 64
Install prefix: /usr
Compiler: gcc
Static libraries: no
Shared libraries: yes
Only host:
configure: summary of build options:
Version: GNU MP 6.0.0
Host type: x86_64-unknown-linux-gnu
ABI: 64
Install prefix: /usr
Compiler: x86_64-unknown-linux-gnu-gcc
Static libraries: no
Shared libraries: yes
No build, no host (as is in the book, now)
configure: summary of build options:
Version: GNU MP 6.0.0
Host type: coreinhm-unknown-linux-gnu
ABI: 64
Install prefix: /usr
Compiler: gcc
Static libraries: no
Shared libraries: yes
These seem to demonstrate that your suggestion is the good one, and the
book is the bad one, if you plan to make copy of the system.
Of course, the book is the best coice, for an optimized system, because
it will tune very well for the processor being used (Nehalem, in my case).
Please. am I correct with the conclusion?
I think that eventually the book will need to include a discussion,
perhaps in a note, in the gmp page.
--
[]s,
Fernando, aka SÃsifo
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
