On 3/4/16, 12:24 PM, "Nick Bowler" <nbowler@xxxxxxxxxx> wrote: >On 2016-03-04, Sean Byland <seanb@xxxxxxxx> 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="..." Thanks this will be useful when experimenting, I’m not sure how I missed that... > > >> 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. I agree that this is good option. The only reason I liked the cache idea is because I thought it would be neat to be able to generate a substantial cache that could be used for multiple autotools projects, so compiles could be performed with users don’t have access to the newer runtime system. > >> 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). I like this and intuitively think that it would be fine in many cases (and will document it). Unfortunately not being familiar with what tests are needed by various autotools projects and what new CPU instructions that Intel add’s with each new generation, I’m hesitant to recommend this as a primary method. Your information has been very informative. Thanks. Sean _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
