Re: Compiling for newer Intel CPUs with an older Intel build system?

[Nick Bowler]

On 2016-03-04, Sean Byland <address@hidden> wrote:
> I’m trying to help users get autotools-based projects to compile in our
> somewhat unique environment. It’s fairly common for users to want to compile
> on a Intel ivybridge system (node) with Intel broadwell-specific (a superset
> of CPU instructions) performance optimization to run elsewhere (a compute
> node). With default options configure won’t handle this scenario because the
> build system can’t execute the Broadwell-specific x86 instructions. In
> varying degrees of success configure will work by:
>
>   1.  Setting --build to a slightly different canonical name to the --build
> name,  indicating to configure that it should do a cross-compile

Just so you know, you can directly force cross compilation mode by
setting cross_compiling=yes, as in:

  ./configure cross_compiling=yes CFLAGS="..."

which might be more straightforward than faking out --build.

>   2.  Generating a config.cache on the Ivybridge compute node, which shares
> the majority of the file system with the Sandybridge system and can
> successfully execute everything. Then point configure on the sandybridge
> system at the cache generated while using the Ivybridge CPU.

This will work fine if the systems are similar enough, although probably
simpler to just directly share the build directories rather than mucking
with config.cache.

>   3.  Setup configure to use a test “launcher,” so configure tests will be
> launched on the Ivybridge system.

Yuck.

> I like option one because it seems to follow a use-case that the autotools
> were designed for but I seem to get regular failures because (for example)
> the packager will use AC_TRY_RUN without defining a sensible
> “[action-if-cross-compiling]”.

Right.  Unfortunately many packages do not properly support cross
compiling.

Do you expect the actual configure test results to matter?  Because
option 4 is to leave the CPU-specific optimizations off when you run
configure, then turn them on when you build.  For example:

  ./configure
  [...]
  make CFLAGS="-O2 -march=broadwell"

Unless some hand-written assembly is being selected based on configure
tests, I expect this would work fine in most cases (but some packages
don't handle user-set CFLAGS properly).

For configure scripts that cache test results, you can also just force
the results of problematic tests by setting the cache variable, as in:

  ./configure foo_cv_xyz=bar

But as with cross-compilation, not all packages support this properly
(and usually the cache variables are not documented).

Cheers,
  Nick