[lfs-support] Ensuring a generic x86_64 build
bruce.dubbs at gmail.com
Mon Sep 18 16:02:49 PDT 2017
Paul Rogers wrote:
>> I noticed this note about GMP:
>> "The default settings of GMP produce libraries optimized for the host
>> Using the default configure settings in the summary of build options I
>> see "Host type: skylake-pc-linux-gnu". I then see gcc is using
>> "-mtune=skylake" when compiling the GMP library. Now if I use
>> configfsf.guess as mentioned in the LFS book, it will build with "Host
>> type: x86_64-pc-linux-gnu". So I've made a note to recompile GMP when
>> I move it to the older system.
> Isn't that a PITA? But check out the "fat" option.
Not really. Do you want performance or portability? The user decides.
In this case the default is performance which I, for one, like.
>> Beyond GMP, is anyone aware of other LFS packages which, when using
>> the default compilation options, could lead to binaries that are
>> tightly coupled to the host build's processor? I'd like my build to
>> be as generic as possible so that it can run on any other x86_64
> I do too, just got into trouble over this and had to rebuild.
> Apparently that is the only package (so far!) to be so presumptuous.
AFAIK, this is it only package in LFS, but it may not be for packages in
BLFS. There is at least one package in multimedia where you need to
disable some optimizations manually. For example gst-libav requires yasm.
Indeed, any package that uses yasm/nasm is a candidate for problems as
those are required for processor instructions not available in C or C++.
More information about the lfs-support