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 > > [ `uname -m` = i686 ] && BUILD_CHOST=i686-unknown-linux-gnu || > [ `uname -m` = x86_64 ] && BUILD_CHOST=x86_64-unknown-linux-gnu && > echo && echo "BUILD_CHOST = $BUILD_CHOST" && echo && > > CONFIGURE="./configure \ > --prefix=/usr \ > --build=$BUILD_CHOST \ > --enable-cxx \ > --disable-static \ > --docdir=/usr/share/doc/${PACKAGE}" && > unset BUILD_CHOST
Hello, 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=. 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. 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. Sincerely, William Harrington -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
